Legacy ImageMagick Discussions Archive

Pictus wrote:...
In my testes, images with heavy PP(post processing) have a tendency to be worst when using
linear light due to the fact that the PP may already have enhanced the details...

Luiz:
Big warning: You are aware that unless you use a version of ImageMagick compiled in HDRI, orthogonal (that is, standard -resize) methods with negative lobes suffer from artifacts that come from colour values beyond the primaries' white and black points being clipped between the two orthogonal passes? (This is not an issue with EWA. This "orthogonal resize with negative lobes" shortcoming of the IM implementation is discussed in another thread.)
Given that I would guess that most often heavy PP has to do with increasing contrast/edge sharpness and making sure the histogram fills the gamut which contribute to more pronounced halos, this would may be why you sometimes get worst results using linear light, at least given that you like standard orthogonal resize methods (and ImageMagick).
Conjecture: Resizing through linear light always looks better if done through floating point.

NicolasRobidoux wrote: With a very recent version of ImageMagick 7, the linear light versions of these schemes are .... With a recent enough version of ImageMagick 6, just replace "magick" by "convert".

I am using the stock binaries at http://www.imagemagick.org/script/binar ... hp#windows. So I presume they are okay with "... -colorspace RGB ... -colorspace sRGB ...". Is it right?

(BTW, are there stock windows binaries for HDRI?
P.S.: found a 6.7.6 version in http://blog.astrophotographytargets.com ... n-windows/)

henrywho wrote:

NicolasRobidoux wrote: With a very recent version of ImageMagick 7, the linear light versions of these schemes are .... With a recent enough version of ImageMagick 6, just replace "magick" by "convert".

I am using the stock binaries at http://www.imagemagick.org/script/binar ... hp#windows. So I presume they are okay with "... -colorspace RGB ... -colorspace sRGB ...". Is it right?

(BTW, are there stock windows binaries for HDRI?
P.S.: found a 6.7.6 version in http://blog.astrophotographytargets.com ... n-windows/)

IM v 6.7.6 may not be current enough. Lots of colorspace changes have occurred since IM 6.7.5.5 and are still being worked out in IM 6, especially with -colorspace gray and -colorspace XXX -separate becoming linear channels.

As far as I know, there are no HDRI binaries provided by IM, even for unix. So you have to compile from source to get into HDRI mode. Sorry I am not a windows user, so cannot help there. see if there is any info at http://www.imagemagick.org/Usage/windows/

It's http://www.imagemagick.org/Usage/windows/ that directs me to that astrophotography blog.

Anyway, I will see if I can compile a more recent version of IM6+HDRI+FFTW with mingw@amd64.

Henry:
First, thank you for looking into this.
Now: Some of the very recent changes in the -colorspace handling should not affect RGB <-> sRGB. So, the precompiled one from the astrophysicists may be just fine. Also: The HDRI issue does not affect EWA methods, so if you want to compare EWA methods with each other, no worries. (Although there is also the linear light issues, and this stuff has changed a lot in multiple ways in the last few months. However I think you don't need absolute bleeding edge.)
Try this, to see if you get the desired results with orthogonal (tensor) methods:This is the result:

If you get the exact same image---or almost exactly the same image---with the astrophysicists' binaries, you're good to go. (I forced the image to be 16 bit so that small differences not disappear by being shoved into 8-bit.) If you only compare EWA methods to each other, or you don't go through linear light (just omit the -colorspace commands), you are good to go even if you don't get bleeding edge, or your IM is less than fresh (or not HDRI).

Looking at the results with the code I gave for linear light processing, linear light looks awful with tensor orthogonal resize.
What is going on?

I know I've discussed this in some form before, but when enlarging, not going through linear light using -colorspace when using a method with negative lobes seems to often give better results, for the simple reason that straight sRGB "dampens" the dark halos (just like going through linear light via -colorspace "dampens" the light halos), and dark halos are often more offensive than light ones. (Think "black eyes".)

-----

If I could be sent on a deserted island with my laptop I'd try to figure out this linear light business once and for all. Grrrr!

(Fred: Yes, one way to minimize both dark and light halos when using a filter with negative lobes would be to send the image through some sort of synthetic S-curve colorspace.)

Well, well, well: Quick visual tests suggest that when enlarging (at least if the input image is sRGB), you're often better off not going through linear light (with -colorspace) when using a 3-lobe windowed Sinc or Jinc (actually, probably any method with a significant negative lobe). Reason: Mostly because of the dark halos, and to a lesser extent light on dark jaggies.
Revised conjecture Downsizing always looks better through linear light if done through floating point. (But not enlarging.)

Nicolas wrote:(Fred: Yes, one way to minimize both dark and light halos when using a filter with negative lobes would be to send the image through some sort of synthetic S-curve colorspace.)

Note sure if this will help as it is not a profile and I don't really know if it is reversible without losing information?

Use -sigmoidal-contrast X,50% for an s-curve and +sigmoidal-contrast X,50% for its inverse? (opposite bending). see my script, sigmoidal at http://www.fmwconcepts.com/imagemagick/ ... /index.php for an example of the transformation curves and its effects.

Fred: Passing things through a sigmoidal transformation and its inverse were indeed exactly what I meant.
Basically, it would go like this (preferably in HDRI):

• 1. Convert to linear light
  2. Apply the inverse of a contrast enhancing sigmoidal transformation.
  3. Enlarge (or rotate or warp) with a negative lobe filter. (This should not be useful for methods without significant negative lobes.)
  4. Apply the contrast enhancing sigmoidal transformation.
  5. Convert from linear light to whatever you came from.

I suspect that because the "sigmoidal colour space" this implicitly defines only differs from the spirit of sRGB near white, and we are less offended by white halo, the benefit will be small in general.
I also would be very surprised if this is useful for downsampling.
So, this is back burner.
P.S. Hopefully I did not get the sigmoidals backward.

Some preliminary downsize testing with the Astro/HDRI binary: while EWALanczos3Sharpest is nearly as sharp as EWALanczos4Sharpest, it seems to ring much less (or acutance?), especially for sharp CG pictures. When I really need acutance, I will use EWA-Lagrange. EWALanczos4Sharpest is sitting somewhere in between.

Thank you Henry. (I know you're very busy.)

My/Fred sigmoidal idea to minimize halos is related to doing the opposite of Henry's -gamma trick that adds acutance, and doing this opposite at both the dark and light ends of the spectrum. That is, one way to understand it is that I want to decrease acutance (the most extreme halos) without losing sharpness.
I'm starting to think that this may be a pretty good idea actually (when enlarging, at least).

Ah! A cheater way would be to take the sRGB image, convert it to reverse video, tag it as linear RGB, convert to sRGB (again!), resize, then undo the extra sRGB and reverse video.

NicolasRobidoux wrote:Henry's -gamma trick that adds acutance.

No, that gamma trick is intended to purposely obtain darker interpolated value, which is much welcomed when downsizing lines or characters on a light background. When the background is dark and the content is light, I do the opposite.

Edit: And the negate-negate trick may not work, coz the light "rings" have dark rings as partners; the negate trick may be simply flipping their lightness.