Crop to 16:9 and zoom with maximal quality

[d-fens_]

Hi,

i have to process a bunch of images from a digital camera at 2256x1504 and zoom into them while the output size is always full-HD (1920x1080).

What i want to archive is the maximal quality so when the zoom factor is 1 (none) the Image should just be cropped to 16:9 cutting on top and bottom and scaled to 1920x1080.
For higher zoom factors the zoom should use the additional pixels of the bigger original image to use optimal quality, but i don't know how to archive this excactly:

No Zoom:
original image -> crop to 16:9 -> resize to 1920x1080

Zoom up to the cropped area(2256x1269) :
original image -> crop to 16:9 -> zoom (will loose information?) -> resize to 1920x1080
should rather be
original image -> crop to 16:9 -> crop another 16:9 area according to zoom level (will not loose infomation)-> resize to 1920x1080

Higher Zoom
original image -> crop to 16:9 -> zoom (will loose information?) -> resize to 1920x1080

can this be done with imagemagick or do i get somehting wrong here?

[snibgo]

If this is for video and you want smooth zooms, I suggest you use "-distort SRT". See http://www.imagemagick.org/script/comma ... hp#distort . SRT enables you to scale to any degree you want, without quantizing to an integer number of pixels.

If these are for stills, you could use SRT or "-resize".

I don't understand your terminology. Higher zoom numbers (x2, x5, x10) normally mean zooming into a picture, enlarging it more.

[d-fens_]

the resulting images are used for a movie afterwards, so i will go with "-distort SRT".

The problem i want to point out is, that for the first zoom levels cropping a smaller 16x9 area of the 2256*1505 image and downscaling to 1920x1080 would be enough - up to the zoom level where the cutout would be smaller than 1920x1080 and the "real" zoom/upscale should kick in.

[snibgo]

When you are losing pixels from the edges, you have to decide how you want to do this. The easiest way is to lose top and bottom equally, and left and right equally, "-gravity center".

Code: Select all

convert in.png -distort SRT 1,0 -gravity center -crop 1920x1080 +repage out.png

Code: Select all

convert in.png -distort SRT 0.8,0 -gravity center -crop 1920x1080 +repage out.png

Code: Select all

convert in.png -distort SRT 1.5,0 -gravity center -crop 1920x1080 +repage out.png

Try it with a real image. You'll soon get the hang of it.

(There is also "-define distort:viewport={geometry_string}" but I've never tried it.)

[d-fens_]

thanks for your reply but the geometry argument without offsets doesn't work, i think its best if i explain in detail.
it starts with https://dl.dropboxusercontent.com/u/341424/test.jpg which has 2256x1504px

cropping it to 16:9

Code: Select all

convert test.jpg  -gravity Center -crop 2256x1286+0+0 +repage   zoom.jpg

which leads to https://dl.dropboxusercontent.com/u/341424/cropped.jpg which has 2256x1286px

if no zoom is wanted i could downscale that to 1920x1080 and done.

but when zooming the image via -distort SRT 1.2,0 the image would be upsampled ( loosing quality ) and then downscaled, even though a crop and downscaling that part would be enough, you see me?

[snibgo]

Sorry, I forgot the "+0+0".

Why would it be "upsampled and then downscaled"? You only need one resampling, which will either be up or down.

You need to resample (only once) and to crop. Cropping twice wouldn't damage the image but you don't need it.

You could resample and crop in either order but it's easier if you resample first, then crop to 1920x1080.

Perhaps I misunderstand you, but I think all you need is

Code: Select all

convert in.png -distort SRT XX,0 -gravity center -crop 1920x1080+0+0 +repage out.png

... for some value of XX.

[d-fens_]

the starting image has the correct aspect ratio (16*9) and resolution > fullhd, my final images should have full HD resolution.

while the source image is bigger than 1920x1080, zooming in is equivalent to cropping a area and then downscale that result to 1920x1080.
information is lost only during downscaling.

on the other hand, with distort zoom > 1, the _full source image_ is upscaled first (quality loss) and then downscaled to 1920x1080 (again lossy), a situation which i seek to avoid.

the problem is that there is no easy relation between the cropping area needed to get scaling factor X ...

[snibgo]

on the other hand, with distort zoom > 1, the _full source image_ is upscaled first (quality loss) and then downscaled to 1920x1080 (again lossy), a situation which i seek to avoid.

When a SRT scale > 1 is specified, IM will create a blank canvas of the same size as the source (2256x1504) then populate those pixels according to the scale factor. Yes, this loses quality, as any resampling does.

There is no need to then downscale to 1920x1080. Just crop.

So if you SRT 1,0 then there is no scaling, just a central crop 1920x1080 of your 2256x1504 image.

If you SRT 2,0 then every pixel will double in size (as if the image was enlarged to 4512x3008, but you only get the central 2256x1504 of these), then you crop.

If you SRT 0.9,0 then the image will be 2030.4x1353.6 but padded out with virtual pixels to 2256x1504. You can crop to 1920x1080 and get real pixels. If SRT scale is less than about 0.85, your crop will include virtual pixels.

[fmw42]

I have not followed all this discussion, but if you want the output to be as large as needed to hold the scaled image use +distort SRT.

You can also use viewport cropping, if so desired.

If the EWA default resampling is too blurry, then add -interpolate XXX -filter point.

See
http://www.imagemagick.org/Usage/distorts/#lookup
http://www.imagemagick.org/Usage/distor ... t_viewport
http://www.imagemagick.org/Usage/distorts/#srt

[d-fens_]

thanks for your replies guys, the reason why i think i do need a downscale and not just crop:

when just cropping to 1920x1080 after +distort SRT, the result will not have the full width of the source image (2256) which i want to keep at "zoomfactor 1", so i have to crop to
2256x1268 (16:9 aspect ratio, full width, top/bottom cropped)

then the 2256x1268 image needs do be down scaled to 1920x1080 to have the final image

so for 1 < zoomfactor < 1,175 a correct calculated crop and downscale would be enough, for higher factors the zoomed pixels must be interpolated

[snibgo]

By "zoomfactor 1" I suppose you mean "give me the full width of the input picture". Then you would use SRT scale 0.85106. (=1920/2256)

Code: Select all

convert test4.jpg -distort SRT 0.85106,0 -gravity center -crop 1920x1080+0+0 +repage o.png

[mrmattnc]

I do this every day! The basics are well covered from other replies (snibgo is a ninja!) but here are some caveats I've ran into in the past

snibgo is absolutely right SRT is the way to go because it allows what I'm going to call sub-pixel movements. For instance if you wanted to go from a height of 10 pixels to a height of 20 pixels across 10 frames (a simple zoom) you'd be good to go since you're always moving in whole pixels (2) such that you can add a pixel on top and bottom and output. The power of SRT is what if you wanted to zoom at 2.4 pixels per frame (or any non trivial number) - using simple +distort you'd get one frame where the pixels are shaved off. Then you go an composite these all in your timeline and you get what I refer to as jitter -- the edge pixels hop around because of the rounding.

A great way to see this is take a 30x50 photo, and do +distort SRT "1.055,0". The output will be 34x54 pixels. 2 pixels are added by SRT so your true size is 32x52, when you're idealized size (by multiplying with a calculator) is 31.65x52.75. If you were doing a zoom and stepped to +distort SRT "1.060,0" the output would be 34x56. And one more step would be +distort SRT "1.065,0", output 34x56. You can already start to see the problem, you've got multiple frames of the same size because the true size is being forced to the lowest denominator of size, an even pixel. Once composited onto output you can imagine these jumps where the edges stair step instead of smoothly zooming.

This exact problem will also surface in minute translations as well. If you're using Sony Vegas or Premiere or any NLE for the final output you're going to see it pop up. Subpixel movement is tough to get right without using something really powerful like After Effects.

The solution here is to use a set background and let SRT handle it all. You want to use a blank canvas your output size as a kind of cookie cutter. Do SRT to handle sub-pixel scaling AND translation, then cookie cutter it via composite onto the output size. You could also accomplish this with cropping, but you've got to nail your math down perfectly -- for me it's easier to just composite with gravity and cookie-cut.

Also, at least under Ubuntu with 6.8.7-9 Q8 scaling down in minute increments takes many times as long as going up - especially for larger pictures. We process in 720p and doing a frame where the picture is scaled using SRT to 0.94 or some small increment takes about 3-5X as long as going up an equal amount, such as to 1.06. I've seen anthony explain it somewhere, I think it has something to do with the way SRT supersamples. To get around this we resize the input image to the smallest size it will be throughout the zoom, and then always scale up. The output looks fine for scaling less than about 30% increase.


Honestly this is a fun, fun project. I've been working on this exact process for a little over a year and hope some of my pain points will save you some headache!

... or you could always download a 30 day trial of After Effects and knock it out.

[snibgo]

I hadn't noticed a speed difference between 0.94 and 1.06 scaling, and a quick test (v6.8.8-0 on Windows 8.1) suggests there is none. But I'm usually working with video frames rather than making a video from stills, so your trick of zooming to the maximum, then then scaling up for each frame, wouldn't help me.

I'll also mention "-distort perspective". Conceptually simpler that SRT and faster, but the arithmetic is messier.

I've never been called a ninja. Ha!

[mrmattnc]

I hadn't noticed a speed difference between 0.94 and 1.06 scaling, and a quick test (v6.8.8-0 on Windows 8.1) suggests there is none. But I'm usually working with video frames rather than making a video from stills, so your trick of zooming to the maximum, then then scaling up for each frame, wouldn't help me.

I'll also mention "-distort perspective". Conceptually simpler that SRT and faster, but the arithmetic is messier.

I've never been called a ninja. Ha!

That is very curious.... perhaps there is a bug in the PerlMagick implementation and not in the core code.

On my Ubuntu dev machine I broke out some old code I was using to speed test sections of our code using perls' HiRes::Time. I ran 30 simulated frames on the same photo using real movements generated from our system.

The run using the minimum size trick and always upscaling averaged 0.4144 seconds/frame. Using the original photo size it averaged 1.2198 seconds/frame. I thought it might have something to do with when you're using the minimum size you have less data to scale which would improve speeds. So I used a background image of equal size and composite the photo in the middle for both runs to generate the data above.

In conclusion I'm not sure if there is a bug, but I need to crank out about 25K frames/hour and the increased speed far outweighs the quality loss for us

[fmw42]

If speed is more important than quality, then add -filter point and use viewport cropping. You can do fx calculations in the viewport crop

convert in.png -background somecolor -virtual-pixel background -define distort:viewport=WxH+X+Y -filter point -distort SRT scale,0 out.png

see
http://www.imagemagick.org/Usage/distor ... t_viewport
http://www.imagemagick.org/Usage/distorts/#lookup
http://www.imagemagick.org/Usage/distor ... red_square