Correct resize

Questions and postings pertaining to the usage of ImageMagick regardless of the interface. This includes the command-line utilities, as well as the C and C++ APIs. Usage questions are like "How do I use ImageMagick to create drop shadows?".
NicolasRobidoux
Posts: 1944
Joined: 2010-08-28T11:16:00-07:00
Authentication code: 8675308
Location: Montreal, Canada

Re: Correct resize

Post by NicolasRobidoux »

anthony wrote: However it is possible for a second distort to be applied to rectangular 'mask' image, which is then used to recover the original images alpha channel in the distorted result. But I have not tried to do this.
The great advantage of treating the alpha channel separately is that you could use a different filter for it. For example, you could use a monotone filter, which would guarantee that alpha channel has no over/undershoot and haloing, e.g. nearest neighbour, bilinear, Hermite, Gaussian blur, Cubic (=B-spline smoothing)...

On the other hand, Anthony has set up a fairly sophisticated way of dealing with transparency in -resize...
Last edited by NicolasRobidoux on 2011-02-01T19:31:45-07:00, edited 3 times in total.
dimkalinux
Posts: 23
Joined: 2011-01-25T11:47:11-07:00
Authentication code: 8675308

Re: Correct resize

Post by dimkalinux »

99% photohosting services even dont use gamma aware scaling - and user happy. But differences very huge - if u can compare images. Im not shure that separately apha-channel processing produce huge differences. Maybe it complicated for practical realization in software, or slow.

Im make little photohosting and i use only shrinking images, not enlarge. Im believe than manual resize with professional software (like photoshop) will produce better result than automatic, but i try make this automatic better :-)
Question: Have you checked whether the above affine/SRT matches the alignment produced by resize exactly both upsampling and downsampling?
My english level or image proccessing level very bad - i dont understand question :-( BTW, im use only downsampling
User avatar
anthony
Posts: 8883
Joined: 2004-05-31T19:27:03-07:00
Authentication code: 8675308
Location: Brisbane, Australia

Re: Correct resize

Post by anthony »

NicolasRobidoux wrote:
anthony wrote:One of its (Mitchel) features is that a no-op resize (IM would short cirtuit in that case though) it produces absolutely no change to the resulting image (Sinc also has that properity)
Mitchel (without short-circuit) does change the image under no-op since the corresponding filter function is not zero at all nonzero integer positions.
Opps yes your are right it is not zero at the integer filter offsets and this does blur an image slightly in a (no-short-cirtuit) no-op resize. Apologies about that. I was not thinking clearly.
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
User avatar
anthony
Posts: 8883
Joined: 2004-05-31T19:27:03-07:00
Authentication code: 8675308
Location: Brisbane, Australia

Re: Correct resize

Post by anthony »

NicolasRobidoux wrote:
anthony wrote: However it is possible for a second distort to be applied to rectangular 'mask' image, which is then used to recover the original images alpha channel in the distorted result. But I have not tried to do this.
The great advantage of treating the alpha channel separately is that you could use a different filter for it
I was not suggesting treating alpha as a separatally filtered channel. But distorting a pure rectangular mask of the whole inptu image (regardless of the images alpha channel), in the same way. that mask can then be used to adjust the edge effects (the fading due to the use of transparent virtual pixels), so as to remove there effect.

Remember originally a transparent virtual pixel was used and then alpha turned off for a distort-resize so as to effectively ignore there contribution to the final image. But if the original image also contains alpha you can not use alpha to remove the effect of virtual pixels from the result! It is an possible suggested alternative to the final -alpha off operation.
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
NicolasRobidoux
Posts: 1944
Joined: 2010-08-28T11:16:00-07:00
Authentication code: 8675308
Location: Montreal, Canada

Re: Correct resize

Post by NicolasRobidoux »

anthony wrote:I was not suggesting treating alpha as a separatally filtered channel. But distorting a pure rectangular mask of the whole inptu image (regardless of the images alpha channel), in the same way. that mask can then be used to adjust the edge effects (the fading due to the use of transparent virtual pixels), so as to remove there effect.

Remember originally a transparent virtual pixel was used and then alpha turned off for a distort-resize so as to effectively ignore there contribution to the final image. But if the original image also contains alpha you can not use alpha to remove the effect of virtual pixels from the result! It is an possible suggested alternative to the final -alpha off operation.
Would a quick and dirty fix consist of first "enlarging" the image slightly by duplicating border pixels (essentially emulating nearest neighbour abyss policy; a bit trickier to deal with corner locations...)? With the current default image size convention, I think that thickening the border by half the filter width would be enough in all cases.
NicolasRobidoux
Posts: 1944
Joined: 2010-08-28T11:16:00-07:00
Authentication code: 8675308
Location: Montreal, Canada

Re: Correct resize

Post by NicolasRobidoux »

Dear dimkalinux:

Just to make sure you understand the gist of Anthony's messages about alpha channels:

With the current set of solutions, using IM distort to resize when there is nontrivial transparency will either remove the transparency or introduce artifacts near the boundary of the image. Consequently, you probably should resize with -resize if you want to preserve transparency.
User avatar
anthony
Posts: 8883
Joined: 2004-05-31T19:27:03-07:00
Authentication code: 8675308
Location: Brisbane, Australia

Re: Correct resize

Post by anthony »

Just a slight correction. The edge effects are not 'artifacts'. It is just a product of the different way the two methods handle edges with regard to filters.

Resize filters ignores any request for a pixel outside the image proper.
Distort filters use the result of the virtual pixel setting for those pixels.
Both filters adjust the filter appropriately for missing values (resize) or transparency (both).

Both methods are correct, depending on what you want the image for, and how 'sharp' you want the edge cutoff to be. Distort is technically more correct, but it is not what most people want when resizing an orthogonal image to a orthogonal image, and especially if the image will not be overlaid into a larger screen.

Resize can produce the equivalent effect as distort by first adding a small transparent border to the original image before resizing appropriately. In that case you get the same 'fadeout' effects.

---
At a deeper level...

Transparency changes the weighting of the filter for color channels. That is so Fully transparent pixels do not add 'black halo' (or some other color) effects to the results. So by using transparent virtual-pixels the color values of the distort-resize will have the equivalent result to resize ignoring virtual-pixels completely. But only for color channel values.

However distort-resize alpha channel values will still be effected by transparent virtual-pixels, producing a alpha channel fadeout effect. But if the original image does not have any proper alpha values, then just turning off alpha will generate a 'correct' color result.

But if alpha channel is present in the original image, then we will somehow need to remove that fade out effect from the results, as simply turning off alpha is not an acceptable solution. By distorting a mask we can get how much alpha fadeout each pixel received, and use it to compensate alpha channel edge effects.

So in summery... The distort-resize method works, and could be make into a operator, but it will fail for images containing alpha.

If we want to make it general enough to work for images with transparency, some extra work is done to compensate the effect on virtual-pixels, but not the effect of transparent pixels. But this adjustment is ONLY for the alpha channel results. Color values are correct thanks to the use of transparent virtual-pixels.

PS: you get similar effects for 'blurs' (convolves) too. Unlike resize, blurs also use virtual-pixels to handle edge effects. Sometimes I wish they didn't, such as when generatign background blur effects. But then when resizing 'tile' images I wish resize also used virtual pixels. At least there is an alternative for that. There are situations when VP and non-VP (orthogonal only) convolution filter methods are needed.
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
NicolasRobidoux
Posts: 1944
Joined: 2010-08-28T11:16:00-07:00
Authentication code: 8675308
Location: Montreal, Canada

Re: Correct resize

Post by NicolasRobidoux »

NicolasRobidoux wrote: Would a quick and dirty fix consist of first "enlarging" the image slightly by duplicating border pixels (essentially emulating nearest neighbour abyss policy; a bit trickier to deal with corner locations...)? With the current default image size convention, I think that thickening the border by half the filter width would be enough in all cases.
(What an idiot.)

Wouldn't switching to

Code: Select all

-virtual-pixel Edge
"fix" the border issues in most situations?

Reference: http://www.imagemagick.org/Usage/misc/#virtual-pixel

P.S.

As Anthony has pointed out elsewhere, -virtual-pixel Edge gives "too much" weight to corner pixels. So, I think that using

Code: Select all

-virtual-pixel Transparent
when there is no transparency, and -virtual-pixel Edge when there is transparency, may be a good practical solution.

P.S. 2

Using the Edge abyss policy when there is transparency is further justified by the fact that most images with an active transparency channel have a transparent border. -virtual-pixel Edge thus "perfectly" extends the input image.
Last edited by NicolasRobidoux on 2011-02-03T14:42:22-07:00, edited 2 times in total.
NicolasRobidoux
Posts: 1944
Joined: 2010-08-28T11:16:00-07:00
Authentication code: 8675308
Location: Montreal, Canada

Re: Correct resize

Post by NicolasRobidoux »

Quick side note about distort filters:

I did a few quick tests, and I believe that distort LanczosSharp is just a bit better than distort Lanczos in terms of visual quality. (Of course, it's not very different, since it is the same filter with extent (support) scaled down by about 2%.)

I've also tried a few other blur values between .82 and .95. Result: Below .95 "jaggies" rear up their ugly heads when upsampling.

I've also compared with Robidoux and, to my eye, it's (still) no contest when upsampling: distort Lanczos(sharp) is sharper, less "jaggy," and more natural looking. (O.K.: Robidoux has less haloing.)

I've not done downsampling tests. My understanding is that dimkalinux prefers Robidoux + USM for downsampling, a very defensible position looking at his/her results, and something I did not expect, although it makes some sense in retrospect.

Given that dimkalinux apparently found both Robidoux and Lanczos a bit "soft," maybe Lanczossharp should also be preferred to Lanczos when downsampling with distort.
User avatar
anthony
Posts: 8883
Joined: 2004-05-31T19:27:03-07:00
Authentication code: 8675308
Location: Brisbane, Australia

Re: Correct resize

Post by anthony »

Using Virtual pixel Edge will solve things to some degree. but using any form of virtual-pixel, or even faking virtual pixels by adding a border, is not actually solving the problem.

Remember the problem is to make distort emulate resize, and resize filters completely ignores virtual pixels. they just don't use them in the calculation.

Using a VP of transparent makes distort ignore VP contributions for Color channels, which is fine if you are going to ignore (turn off) alpha at the end. However as transparency channls is still effected you can't just turn off alpha channel at the end (original image has some transparency.

You can use VP edge, but then edge pixels get replicated outward from the image, making edge pixels influence the filtered result (assuming it is just for alpha). And an even stronger effect for corners.

VP mirror can work better, but the filter will still not ignore alpha.

HOLD THE PRESS...

When a VP transparency is used. Color channel results are not VP effected (as VP pixels are transparent)!

Solution....
  • clone image, extract alpha as a greyscale image, with a opaque alpha channel.
  • Now you have two images, the original (with its own alpha), and the alpha in color channels!
  • Do the resize distort on both and turn off alpha on both.
  • Now merge the second alpha channel image back into the original image (compose CopyOpacity is good for this).
As the second 'alpha mask' image was resized using only color channels it will also be not be VP effected! Just like the color channels in the original image (though the first image has alpha edge effects)

test image, a half circle on edge.

Code: Select all

     convert -size 70x70 xc:none  -fill red -draw 'circle 35,65 15,55'  hcircle.png
Image
Try resizing this image with a very 'large' filter, to see how the filter effects results near edge. A very blurry gaussian should be good for this test!

Resize (with large vastly over blurry gaussian)

Code: Select all

   convert hcircle.png -filter gaussian -define filter:blur=10 -resize 100x100 hcircle_resize.png
Image
Note that this is what we want to achieve in distort, with gaussian resize filter we should get a almost perfect match.

Now try this with distort and VP transparency (without the final alpha turn off).

Code: Select all

  convert hcircle.png  -alpha on -virtual-pixel transparent \
        -filter gaussian -define filter:blur=10 \
        +distort Affine '0,0 0,0   70,0 100,0   0,70 0,100' \
        -crop 100x100+0+0 +repage  hcircle_distort_vp.png
Image
Note the effect of the VP transparency on the edge. The color values are right, just alpha is not. And it is only an edge effect, though in this case the effect is up to 20 pixels inward from the edge. Actually it is outward too. but IM distort only provides a 1-2 pixel buffer for the outward effect, and we use crop to remove it.

Now lets try separating alpha and distorting that channel in the color channels to remove VP effects on it. Remember -distort can distort a list of images all in the same way!)

Code: Select all

  convert hcircle.png -alpha set -virtual-pixel transparent \
        \( +clone -alpha extract -alpha opaque \) \
        -filter gaussian -define filter:blur=10 \
        +distort Affine '0,0 0,0   70,0 100,0   0,70 0,100' \
        -crop 100x100+0+0 +repage \
        -alpha off -compose CopyOpacity -composite \
        hcircle_distort_alpha.png
Image

A practically perfect distort-resize with an image containing alpha and all VP effect ignored!

Yes yes Yes!!! 8)

ASIDE: the distort use of gaussian is slightly different to the resize version. The Bluring is slightly larger as a sqrt(2) 'blur' factor was internally included as per suggestions from some research articles on the use of 2D filters. With this example I think that blur factor difference may be a mistake, and probably should be removed. It may also be that my implementation was not quite right.

NOTE: Gaussian is a 2-pass separable function, as such as a filter it should produce the same results if used as a 2 pass orthogonal filter (resize), or as a 1 pass cylindrical filter (distort).

UPDATE: the blur factor is now the same for orthogonal or cylindrical filters
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
NicolasRobidoux
Posts: 1944
Joined: 2010-08-28T11:16:00-07:00
Authentication code: 8675308
Location: Montreal, Canada

Re: Correct resize

Post by NicolasRobidoux »

8) totally deserved: Speak of an elegant "no painful C programming required" solution!

Question: Is it possible to pretend, in IM, that an alpha channel is not an alpha channel, just an extra colour band (almost like CMYK or an image representing separated colour plates, but without cross-over of pseudo-colour bands), and then restore the "last channel is actually an alpha channel" status once this part of the processing is done?
anthony wrote: ASIDE: the distort use of gaussian is slightly different to the resize version. The Bluring is slightly larger as a sqrt(2) 'blur' factor was internally included as per suggestions from some research articles on the use of 2D filters. With this example I think that blur factor difference may be a mistake, and probably should be removed. It may also be that my implementation was not quite right. Comments Nicholas?
I believe you took the sqrt(2) from the article by Craig DeForest. His concern is spectral properties of the result, not how it looks: no frequency aliasing whatsoever. Don Munsil, on the other hand, has made the point over and over that spectral properties are irrelevant when one cares about things "looking good." (Every time, the spectral posse jumps on him, waving Lanczos in his face, but when I ran into his posts I couldn't help but think "Yes!" And yet I'm the Jinc-windowed Jinc pusher. Go figure.)

Conclusion: Why don't you set the scaling so you get the same result (well, up to the different LUT set up, "truncation" of the tail, etc) whether you distort or resize and make yourself happy?

Everybody understands that sigma is something which is to be tweaked to taste. If you set the sigma all around to a value people expect (1?), then hopefully they can figure to use -define filter:blur=sigma_value_they_want to get what they want.
dimkalinux
Posts: 23
Joined: 2011-01-25T11:47:11-07:00
Authentication code: 8675308

Re: Correct resize

Post by dimkalinux »

I'm use -background #ffffff in all resize and i think it make all transparent pixels are white. is not?
I'm read than images resized in IM with transparent preserve may cause that on Internet Explorer (maybe old version?) will display this transparent pixels as black. Cant testing because haven't IE, but -background #fff seems to be work good.

Looking now on differences between distort and resize on my opinion on practical is:
1) Distort produce slight better sharping images with text - f.e. screenshots.
2) With Distort u can better tuning USM - in resize USM is more aggressively - it look better on 95% images but on images like fly it can produce artifacts - distort better in this area.
NicolasRobidoux
Posts: 1944
Joined: 2010-08-28T11:16:00-07:00
Authentication code: 8675308
Location: Montreal, Canada

Re: Correct resize

Post by NicolasRobidoux »

Anthony:

If I was to make a guess as to whether the same filter should be used for the alpha channel (now that you have produced its own "track"), I'd say probably not. (Although distort Robidoux is only mildly sharpening, so it probably would work OK with alpha too.) You should really prefer a "monotone" (no negative lobes) filter here, or at least one with only one negative lobe, and a mild one at that. So, I'd go with gaussian with a small sigma, which means that the alpha channel can be processed with resize.

And then there is the question of whether to subject the alpha channel to USM. My guess is "No." But it is just a guess: I am not sure I know what the varied typical uses of transparency are in general, and I tend to think in terms of upsampling, not downsampling.

If my hunch is right, the colour channels are pushed through distort (with Robidoux or LanczosSharp) + USM, and the alpha channel is pushed through resize (with Gaussian) without USM, and then things are reassembled. This is when downsampling; when upsampling, skip USM altogether (of course?).

(I've not done any tests.)
Last edited by NicolasRobidoux on 2011-02-04T11:30:10-07:00, edited 5 times in total.
NicolasRobidoux
Posts: 1944
Joined: 2010-08-28T11:16:00-07:00
Authentication code: 8675308
Location: Montreal, Canada

Re: Correct resize

Post by NicolasRobidoux »

dimkalinux wrote: 1) Distort produce slight better sharping images with text - f.e. screenshots.
2) With Distort u can better tuning USM - in resize USM is more aggressively - it look better on 95% images but on images like fly it can produce artifacts - distort better in this area.
Thank you for the precision. If I get the drift of 2), I'd try "distort results sharpen up more naturally." Does this description sound accurate to you?
dimkalinux
Posts: 23
Joined: 2011-01-25T11:47:11-07:00
Authentication code: 8675308

Re: Correct resize

Post by dimkalinux »

NicolasRobidoux wrote:If I get the drift of 2), I'd try "distort results sharpen up more naturally." Does this description sound accurate to you?
Default distort produce some blurred images as and resize or as any other resize algo.
But, with distort i can more accurately tune USM parameters and it produce less-artifacted images - it visible only on some images - f.e. with text or images with think lines.

Example
resize
Image

distort
Image
On distort text is more sharpen and contrasted.

In ideal - for photo use resize (lanczos) + usm, on human or pc generated images - distort with mitchell-like filter and tuned USM by size and scale value too.

But it very difficult with any algorithm - now i think than more sharpen images is not always is more quality or better images. Good sharpen parameters on one images produce over-sharping on other type of images. I told only about of automatic resizing (batch resizing).

Differences very very small and visible only in compare. I think is because IM resizing is very good.
Post Reply