Legacy ImageMagick Discussions Archive

dimkalinux:

The differences are very noticeable in your two screenshots (look, for example, at the corners, and the number 2 at bottom left). I'm having trouble, however, telling what the contribution of the filter is compared to USM's. Could you post the code?

It looks to me like the amount of haloing is about the same in both (slightly more for distort, I think). Given that the text is considerably sharper with distort, it looks like a clear win for distort.

Side note: Your tests have made me finalize the decision of which filters to program next for VIPS and GEGL. Thank you. (I don't want to write here about what they are: I've discussed my non-IM projects enough elsewhere on this list.)

NicolasRobidoux wrote: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?

Something like that could be done with a special -channel switch. Somthing like the current special 'Sync' switch.

However your exact suggestion will not work. You can not make alpha channel, alpha effected! As you do for the color channels!

Think about it! It is just plain silly! Alpha must not effect Alpha! You'd get a non-sense result!

In my example what is happening is that color channels (first image) are BOTH alpha effected (alpha was not turned off before distort), and all effects from virtual-pixels also ignored (as they are fully transparent).

However the alpha channel (second image) only ignores VP pixels, as only VP pixels are fully transparent, the rest of the second image is fully-opaque! The results then merged together again.

What we really want is all channels to basically ignore 'virtual-pixels', just as resize does.
That is color channels alpha weighted and VP ignored, and alpha channels just VP ignored.

Implementing this however is difficult and would effectually slow down the filter convolution processing, as you need to test if the pixel value being looked at by the convolution filter, is a VP or not. Basically the underlying sub-routine returning pixels would also then need include that information. Resize does not look up VP pixels, as it is perly a orthogonal process. Distort has to as the lookup points are far less predictable. Also for a normal distort use, such a test is rather useless. It is really only useful for image distortions that go from orthogonal to orthogonal shapes.

No your suggestion would not work. But the solution I provided above would be useful for the implementation of a special -distort-resize type operator. I am sure such an operator could be easily added. The only problem is that it is about 2.5 times slower that a non-alpha distort-resize.
Rememebr distort (convolution) is much heavier in processing than a pixel-by-pixel compose which is why 1/2.

NicolasRobidoux wrote: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.

Okay. we are both in agreement. I will adjust things so Gaussian filter results are the same for BOTH resize and distort. Becides it will also make it a lot easier for 'variable blur composition' which uses the underlaying distort EWA to implement its variable convolution handling. At the moment I have tweeks in it to remove that sigma modification.

Mind you var-blur also currently does handle very small blurs properly, as the filter support starts to 'miss' all neighbouring pixels, so only returning the exact original pixel, especially on highly elliptical blurs. I have a fix for this in the works, just not implemented.

When I get to it is another matter. Start of University Semester in a few weeks leave me little time. I have noted it in my ToDo list.

dimkalinux wrote: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.

The above discussion ignores the effect of color from fully-transparent pixels. That is the major point as to why using VP transparent works as a 'hack' to make distort-resize do what is wanted. It it did you would get effect such as shown in the very OLD bug report page...
http://www.imagemagick.org/Usage/bugs/resize_halo/
That page is only kept as reference such as now. It was fixed a very long time ago.
Even distort had that bug for a short period when first implemented (my bad).

Many IM operators resets fully-transparent pixels to a mathematical zero, that is "black", but only fully-transparent pixels.

Before saving you can use -background {color} -alpha background to reset fully-transparent colors to something else.

Note this is different to the -transparent-color setting, which defines the color used for full-transparency in a index color table. That is for GIF or PNG8 boolean transparency.
See GIF Transparency Color
http://www.imagemagick.org/Usage/formats/#gif_trans

NicolasRobidoux wrote: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've not done any tests.)

I would be very careful. If you use two different filters it is possible that you make a pixel that should be fully transparent, partially transparent when the images are recombined. As long as fully transparent is more likely in the result there should be no problem.

This is actually why Mitchell is used instead of Lanczos for shrinking images involving a color palette (limited colors such as in GIF) or transparency. To avoid positive ringing effects.

For IM resize filter defaults see
http://www.imagemagick.org/Usage/resize/#default_filter

NicolasRobidoux wrote:dimkalinux:
The differences are very noticeable in your two screenshots (look, for example, at the corners, and the number 2 at bottom left). I'm having trouble, however, telling what the contribution of the filter is compared to USM's. Could you post the code?

Resize

Code: Select all

/usr/local/bin/convert.hdri '/var/upload/pic2/1/d19f33/4bc3adff.png' -depth 16 -colorspace sRGB -filter Mitchell  -auto-orient  -resize 675x640\> -quality 95  -sampling-factor 1x1  -unsharp 0x0.8+0.55+0.007  -background "#ffffff"  -colorspace RGB -clamp -depth 8 png:'/tmp/piclgua_icuh3Na2'

Resize time - 4 created images differents sizes - upload time: 2.445 seconds
I test this screenshots also with Lanczos - but Mitchell is better for text.

Distort

Code: Select all

/usr/local/bin/convert.hdri '/var/upload/pic2/1/a1e31f/4bc3adff.png' -depth 16 -colorspace sRGB  -auto-orient  -alpha on -virtual-pixel transparent +distort Affine "0,0 0,0   %w,0 675,0   0,%h 0,640" -crop 675x640+0+0 +repage -quality 95  -sampling-factor 1x1  -unsharp 0x0.8+0.55+0.007  -background "#ffffff"  -colorspace RGB -clamp -depth 8 png:'/tmp/piclgua_icFzFhkC'

Distort time - 4 created images differents sizes - upload time: 3.55 seconds

dimkalinux wrote:
Resize
Code: Select all
...-unsharp 0x0.8+0.55+0.007...
Resize time - 4 created images differents sizes - upload time: 2.445 seconds
I test this screenshots also with Lanczos - but Mitchell is better for text.

Distort
Code: Select all
...-unsharp 0x0.8+0.55+0.007...
Distort time - 4 created images differents sizes - upload time: 3.55 seconds

So, you used the same USM for both. Conclusion: Distort Robidoux is inherently sharper than Resize Mitchell (and it looks so given the haloing). And, when the whole tool chain is taken into account, distort is not much slower than resize (45%).

anthony wrote:
NicolasRobidoux wrote: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've not done any tests.)
I would be very careful. If you use two different filters it is possible that you make a pixel that should be fully transparent, partially transparent when the images are recombined.

Hmmm. Indeed I think the "separate filter for alpha" is something that would need to be carefully tweaked and tested. Manana.

I am just committing into the SVN the -distort equivalent of -resize (for both cases of no-transparency and images with transparency) as discussed in viewtopic.php?p=68362#p68362

As such as of IM 6.6.9-2 a new method -distort Resize "geometry" can be used.

Note that this is really a 'compound distortion', in that it is not actually directly distorting an image in a new way, but making calls to other distortion methods and other image processing operators to perform its action.

The new "distort resize" works beautifully. Compare, e.g.,

Code: Select all

convert rose: -alpha Off -filter quadratic -distort Resize 1024x1024 quadratic_distort.png

to

Code: Select all

convert rose: -alpha Off -filter quadratic -resize 1024x1024 quadratic_resize.png

(barely any difference, which is unsurprising since quadratic is an approximation of Gaussian blur, which is (in theory) the same as a tensor method or an EWA method) or

Code: Select all

convert rose: -alpha Off -filter LanczosSharp -distort Resize 1024x1024 lanczossharp_distort.png

to

Code: Select all

convert rose: -alpha Off -filter Lanczos -resize 1024x1024 lanczos_resize.png

where the "sharp" version of Jinc-Jinc Lanczos shows very different results than the standard Sinc-Sinc Lanczos (in particular, Jinc-Jinc LanczosSharp is almost as sharp as Sinc-Sinc lanczos, but it is remarkably free of jaggies).

It also switches to the 'transparency handling double distort' technique if the input image has alpha enabled.

So if you positivity know the image has no transparency, it is best to ensure alpha is turned off

Another comparison that I find instructive:

Code: Select all

convert logo: -alpha Off -filter lanczos -resize 2024x2024 lanczos_resize.png
convert logo: -alpha Off -filter lanczos -distort Resize 2024x2024 lanczos_distort.png
convert logo: -alpha Off -filter lanczos2 -distort Resize 2024x2024 lanczos2_distort.png
convert logo: -alpha Off -filter lanczos2 -resize 2024x2024 lanczos2_resize.png

Here is a flicker compare of just one filter without needing to save the image....

Code: Select all

convert rose: -filter Mitchell \
            \( -clone 0 -resize 500x -set label 'Resize' \) \
            \( -clone 0 -distort Resize 500x -set label 'Distort' \) \
            -delete 0 miff:- | flicker_cmp -l %l -

In this case you can see that mitchell filter is not as good in a distort.

Doing a run with resize Mitchell verses distort Robidoux filters seems to show that for these really small filters resize is still better. But then you can't rotate or apply other distortions

Distort Jinc however is superior to Resize Sinc on diagonals.

anthony wrote:...
Distort Jinc however is superior to Resize Sinc on diagonals.

Distort Jinc also produces what appears to me to be less jarring and actually slightly smaller (in terms of amplitude) halo. Also, distort Lanczos2 (in plain or sharp versions) appears to be quite good at downsampling (reducing images).

I'll keep comparing around. With your new tool it is a pleasant task.

(I don't particularly like the Robidoux (and the closely related Lanczos2Sharp and Mitchell) distort (EWA) filters. Resize (tensor) Mitchell is, of course, a very good all-purpose filter.)

I do like "plain" distort Lanczos2, as well as both distort Lanczos and the almost identical distort LanczosSharp, a lot. These EWA Jinc-Jinc filters are, in addition, quite different from the tensor Sinc-Sinc counterparts; unsurprisingly, Lanczos (default 3 lobes) gives more haloing than Lanczos2. Distort Lanczos2, IMHO, gives results analogous to resize Mitchell, except that it has less jaggies and "zebra striping" (weird wisps that create "ladder rungs" between nearby oblique interfaces or lines) and slightly less noticeable haloing, and yet it manages to be slightly sharper.

If I was the king of the universe

I think I'd make distort Lanczos2 the default.

If I don't want any halo whatsoever, I do like both resize and distort Quadratic, even though it is less sharp than resize Mitchell.

(The above are preliminary results: More careful comparison needs to be done.)

No matter how much I like it, I'm not sure rose is the very best test image for enlargements because it appears that this thumnail was produced with some sharpening or most likely a ringing scheme (I'd guess (tensor) Lanczos 3 lobes).

Consequently, enlargements with a "ringing" scheme will amplify the artificially created halos, and consequently will have more haloing than would be the case with less processed images.

Legacy ImageMagick Discussions Archive

Correct resize

Re: Correct resize

Re: Correct resize

Re: Correct resize

Re: Correct resize

Re: Correct resize

Re: Correct resize

Re: Correct resize

Re: Correct resize

Re: Correct resize

Re: Correct resize

Re: Correct resize

Re: Correct resize

Re: Correct resize

Re: Correct resize

Re: Correct resize