RSS/Atom feed Twitter
Site is read-only, email is disabled
  1. Chat
  2. Useful links
  3. Polls

Featured content

Does "Hue", "Saturation", "Value" layer modes need HSV? How about CIE LCH instead?

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

Martin Nordholts
2009-08-02 11:47:35 UTC (over 15 years ago)

Does "Hue", "Saturation", "Value" layer modes need HSV? How about CIE LCH instead?

Hi,

The "Color" layer mode has since long produced bad results, see bug 325564 [1] for a way to see this. The cause is a combination of rounding errors due to 8bit processing and poor properties/usage of the underlying color model HSL.

I have just implemented Color based on the CIE LCH color model when GEGL is used for the projection. This gives much better results, see the bug report for samples.

Now, I would also like to port Hue, Saturation and Value to CIE LCH. They are currently using the HSV color model with the same problems as HSL. If we switch to CIE LCH we would also change name of "Value" to "Lightness".

Does anyone see any problems with using CIE LCH instead of HSV for these layer modes? We can ignore backwards compatibility issues for now.

Thanks in advance for any input

/ Martin

[1] Bug 325564 – Use CIE LCH instead of HSL for layer mode "Color" http://bugzilla.gnome.org/show_bug.cgi?id=325564

SHIRAKAWA Akira
2009-08-02 12:19:34 UTC (over 15 years ago)

Does "Hue", "Saturation", "Value" layer modes need HSV? How about CIE LCH instead?

Martin Nordholts wrote:

Does anyone see any problems with using CIE LCH instead of HSV for these layer modes? We can ignore backwards compatibility issues for now.

I very rarely use layer modes (and I'm not a GIMP hacker so I'm probably missing something), but if using internally CIE LCH for image processing instead of HSV leads to more correct results, then I wouldn't see any reason to not use it.

Except for the final results, will there be any change at a user interaction level? Or any practical drawback resulting from this?

Martin Nordholts
2009-08-02 12:42:21 UTC (over 15 years ago)

Does "Hue", "Saturation", "Value" layer modes need HSV? How about CIE LCH instead?

On 08/02/2009 12:19 PM, SHIRAKAWA Akira wrote:

Martin Nordholts wrote:

Does anyone see any problems with using CIE LCH instead of HSV for these layer modes? We can ignore backwards compatibility issues for now.

Except for the final results, will there be any change at a user interaction level? Or any practical drawback resulting from this?

My main concern is regarding the Value layer mode since the name Value is tightly coupled with how it is implemented. I figured there might be some esoteric use case I'm not thinking about where this implementation characteristic matters.

Using CIE LCH Lightness will make the layer mode be based on perception of lightness instead of value in HSV, and for the purposes I can come up with, using CIE LCH Lightness will always be better.

For the user, the only difference will be a different name for a layer mode (Value -> Lightness) and to my knowledge more intuitive results.

/ Martin

David Gowers
2009-08-02 12:59:36 UTC (over 15 years ago)

Does "Hue", "Saturation", "Value" layer modes need HSV? How about CIE LCH instead?

On Sun, Aug 2, 2009 at 7:49 PM, SHIRAKAWA Akira wrote:

Martin Nordholts wrote:

Does anyone see any problems with using CIE LCH instead of HSV for these layer modes? We can ignore backwards compatibility issues for now.

I very rarely use layer modes (and I'm not a GIMP hacker so I'm probably missing something), but if using internally CIE LCH for image processing instead of HSV leads to more correct results, then I wouldn't see any reason to not use it.

Except for the final results, will there be any change at a user interaction level? Or any practical drawback resulting from this?

LCH processing is definitely slower than HSV or HSL (whether optimized or not), so this may have an impact on display update speed (and consequently on user experience)

There are a few different ways of applying a 'Color' like operation, varying in quality and speed.
LCH is certainly the best quality, Yiq is lesser quality but faster, HSL is even lesser quality and very fast, HSV is the fastest (but so inaccurate it's laughable)

Since GEGL provides a number of operations that are inherently expensive (eg bilateral-filter), it may be worth considering the idea of graphs with quality controls built in. For example, while you are painting on your Color layer, it switches from paint application using LCH to Yiq (which is a nice compromise and has been used for heavy-duty tasks with good results -- see http://www.cs.huji.ac.il/~yweiss/Colorization/). When you stop painting, it updates with the actual LCH results. This would allow more responsive painting (and could also be applied to paint modes)

Martin: I have made use of GIMP Value mode in the esoteric kind of way you mention. I agree it is not worthwhile to support such uses (imo more like abuses -- this kind of use is really begging for the use of PIL or NumPy on a chunk of image, not the application of an image *editor*)

Martin Nordholts
2009-08-02 13:12:00 UTC (over 15 years ago)

Does "Hue", "Saturation", "Value" layer modes need HSV? How about CIE LCH instead?

On 08/02/2009 12:59 PM, David Gowers wrote:

LCH processing is definitely slower than HSV or HSL (whether optimized or not), so this may have an impact on display update speed (and consequently on user experience)

Problems with real-time responsiveness when using LCH is a good point, and using a quicker less accurate method while painting is a good idea.

We should do other tricks when painting too for increased performance, such as only applying a brush to the smallest possible mipmap level. That way it will be possible to paint with huge brushes on huge images in a zoomed out view with real-time response and projection update. Dealing with these optimizations in a generic way would be nice.

/ Martin

Emil Assarsson
2009-08-02 14:29:54 UTC (over 15 years ago)

Does "Hue", "Saturation", "Value" layer modes need HSV? How about CIE LCH instead?

Nice work Martin :-)

I'm trying to make a valid comparison of the two images from PS and Gimp but it seems like the have block distortions from jpeg compression or something?

I mostly use the color layer mode for overlay painting on black and white sketches. Here is an example of the use: http://www.androidblues.com/JealousyStepbystep/jealousystep.html . This technique is not that sensitive of exact color mapping. Another use is to select areas based on their hue and color replacement. The problems arises when I combine tools that uses different color spaces.

Martin Nordholts
2009-08-02 21:41:30 UTC (over 15 years ago)

Does "Hue", "Saturation", "Value" layer modes need HSV? How about CIE LCH instead?

The input I've gotten so far removed any remaining doubt about porting those layer modes to LCH, so I've done that now:

commit 18603ac192493296b191197a3e2b62c710398afd Author: Martin Nordholts
Date: Sun Aug 2 21:35:10 2009 +0200

Bug 401754 – Port Hue, Saturation, Value to CIE LCH

When using GEGL for the projection, use CIE LCH for the Hue, Saturation and Value layer modes, just as we already do for the Color layer mode. The Value layer mode will later be renamed to Lightness since that is the semantics it has now.

/ Martin

David Gowers
2009-08-03 03:12:14 UTC (over 15 years ago)

Does "Hue", "Saturation", "Value" layer modes need HSV? How about CIE LCH instead?

On Mon, Aug 3, 2009 at 5:13 AM, Martin Nordholts wrote:

The input I've gotten so far removed any remaining doubt about porting those layer modes to LCH, so I've done that now:

commit 18603ac192493296b191197a3e2b62c710398afd Author: Martin Nordholts
Date: Sun Aug 2 21:35:10 2009 +0200

Bug 401754 – Port Hue, Saturation, Value to CIE LCH

When using GEGL for the projection, use CIE LCH for the Hue, Saturation and Value layer modes, just as we already do for the Color layer mode. The Value layer mode will later be renamed to Lightness since that is the semantics it has now.

oh, BTW, since LAB already separates the color element (AB) from lightness, it's probably better to just use LAB for that -- it should produce identical results, faster.

David