Legacy ImageMagick Discussions Archive

Win32 ImageMagick 6.7.8-10 2012-08-10 Q16 DLL
"rings_sm_lab1.png" and "rings_sm_lab2.png" remains gray
"rings_sm_luv1.png" and "rings_sm_luv2.png" has a blue cast with color dots everywhere.

"rings_lg_orig.png" is the sample picture used in the ImageMagick online documentation.

We checked the conversion and the algorithm appears to be correct per http://www.brucelindbloom.com/index.html?Equations.html. We visually verify with this command:

• -> convert rose: -colorspace luv -colorspace srgb rose.png
  -> compare -metric rmse rose.png rose: null:
  0 (0)

We repeat with a few more images and each returns a 0 RMSE suggesting a distortion free round trip.

This suggests that the conversion to and from LUV is correct. However, we are not familiar with the shape of the LUV colorspace. Perhaps it does not map well to the RGB color cube and there is a loss going between the two colorspaces. Anthony / Nicholas / Fred can you comment?

Not sure if it is something like rounding errors:

magick wrote:This suggests that the conversion to and from LUV is correct.

It seems the resize (and distort resize too) codes are not behaving properly under LUV.

Have you tried under HDRI compile to see if it behaves differently there?

fmw42 wrote:Have you tried under HDRI compile to see if it behaves differently there?

no, coz the HDRI build (ImageMagick 6.7.6-1) is old and it does not support LUV.

henrywho wrote:

fmw42 wrote:Have you tried under HDRI compile to see if it behaves differently there?

no, coz the HDRI build (ImageMagick 6.7.6-1) is old and it does not support LUV.

I can try to test under HDRI on my Mac.

Magick wrote:Anthony / Nicholas / Fred can you comment?

The rings image is grayscale under IM 6.7.8.3 and higher and not sRGB. So it should be converted and not set to sRGB before processing.

This is what I get. I would agree that LUV result does not look reasonable and I would think there is a bug.

I am testing under IM 6.7.8.10 Q16 HDRI on Mac OSX Snow Leopard.

Here are tests for both LAB and LUV.

Original:
http://www.imagemagick.org/Usage/resize ... g_orig.png


Convert to sRGB:

imh convert rings_lg_orig.png -colorspace sRGB -colorspace LUV -resize 25% -alpha off +repage -colorspace sRGB -quality 95% rings_sm_luv3.png



imh convert rings_lg_orig.png -colorspace sRGB -colorspace LAB -resize 25% -alpha off +repage -colorspace sRGB -quality 95% rings_sm_lab3.png



Leave as grayscale:

imh convert rings_lg_orig.png -colorspace LUV -resize 25% -alpha off +repage -colorspace gray -quality 95% rings_sm_luv4.png



imh convert rings_lg_orig.png -colorspace LAB -resize 25% -alpha off +repage -colorspace gray -quality 95% rings_sm_lab4.png

fmw42 wrote:The rings image is grayscale under IM 6.7.8.3 and higher and not sRGB.

I thought the image is "sGray" and so I use "-set colorspace sRGB" (not "-colorspace sRGB") before "-colorspace LUV" and "-colorspace LAB". Is it causing the troubles?

It seems that your LUV images do not have any color cast.

henrywho wrote:

fmw42 wrote:The rings image is grayscale under IM 6.7.8.3 and higher and not sRGB.

I thought the image is "sGray" and so I use "-set colorspace sRGB" (not "-colorspace sRGB") before "-colorspace LUV" and "-colorspace LAB". Is it causing the troubles?

Your LUV images seem not having any color cast.

IM is now interpreting grayscale images as linear gray, since IM 6.7.8.3 and not sGray. The latter would likely have gamma=0.4545 and this image shows gamma=1 in IM 6.7.8.10.


Image: rings_lg_orig.png
Format: PNG (Portable Network Graphics)
Class: PseudoClass
Geometry: 1000x1000+0+0
Resolution: 72x72
Print size: 13.8889x13.8889
Units: Undefined
Type: Grayscale
Base type: Grayscale
Endianess: Undefined
Colorspace: Gray
Depth: 8-bit
Channel depth:
gray: 8-bit
...

Rendering intent: Undefined
Gamma: 1


I don't see any colorcast. But I do not like how much contrast the result has. That does not look reasonable to me, though I am not an expert on colorspace and especially LUV.

If I do the same in non-hdri, I get more reasonable looking results from LUV, but you are right in that it has a bluish color case.


convert rings_lg_orig.png -colorspace sRGB -colorspace LUV -resize 25% -alpha off +repage -colorspace sRGB -quality 95% rings_sm_luv3_nonhdri.png



convert rings_lg_orig.png -colorspace sRGB -colorspace LAB -resize 25% -alpha off +repage -colorspace sRGB -quality 95% rings_sm_lab3_nonhdri.png



So HDRI mode (earlier post) is producing a worse result, but non-HDRI mode does not look right either due to the bluish color where it should be pure gray.

The brightness should be incorrect because of the incorrect gamma assumption. Still the image should remain gray only. One bug in Q16 compiles is that the image is no longer gray.

Another bug in Q16 compiles is having abnormal dots generated. The following sample has a light gray dot at the 6-o-clock position near the center:

We can reproduce the problem you posted and have a patch in ImageMagick 6.7.9-1 Beta available by sometime tomorrow. Thanks.

In the latest 6.7.9.1 beta:

Both look pretty good now. I see only a slight darkening above and below the central rings in the output of the non-hdri. The hdri one looks perfect. Neither show any bluish tint.

But this is not working, Oppisite problem white going black....

convert rose: -define modulate:colorspace=HCL -modulate 150,100,100 show:

Brightening an image in HCL colorspace.