Legacy ImageMagick Discussions Archive

The LUV colorspace is in some cases showing errors. basically for very very dark/bright pixels, you can get a negated result.
This is not the case with the very similar LAB colorspace.

For example resizing the earth lights image in LAB produces a good image...

BUT doing this in LUV colorspace results in some VERY bright pixels where none should appear. These pixel should be near black, as it is in the previous example.


Compare the images and look at the pixels for Falkland islands in south Atlantic, for Nauru in the West Pacific, along the edge of the artic icecap, and two bright pixels in Russia.

Basically while LUV colorspace seems to be working, there is some error at extreme values.

try it in HDRI

PM from Magick:

Note, there is still a slight differential when using LUV without HDRI-enabled.  This is due to the scaling / clamping required for LUV, see http://framewave.sourceforge.net/Manual ... 00330.html.

I can't see anything in there that can cause a clamping issue. But then the formula is for the to LUV direction
it is more likely to be the reverse that is the problem.

Of course this is actually mapping sRGB -> RGB -> XYZ -> LUV so that is a long chain of conversions to apply.

The reverse from the function list
http://framewave.sourceforge.net/Manual ... rames.html
using the second LUVtoRGB group also appears to be relatively straight forward.
http://framewave.sourceforge.net/Manual ... 0060_00340

Of course clamping is applied before mapping the values back to the final unsigned 16bit integers (last step in the above chain) bout that should not cause a sudden negation of the color.

Seems pure LUV roundtrip is okay .... but not if resizing is done under LUV

viewtopic.php?f=3&t=21664

I would expect there and back working. But inverting LUV colors that don't convert well to RGB is not a good solution.