[Gimp-developer] 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 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? -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Does Hue, Saturation, Value layer modes need HSV? How about CIE LCH instead?
On Sun, Aug 2, 2009 at 7:49 PM, SHIRAKAWA Akira shirakawa.ak...@gmail.comwrote: 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*) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] XMPModel and custom signals
Hi Martin,
On Sat, Aug 01, 2009 at 09:32:36AM +0200, Martin Nordholts wrote:
On 07/31/2009 07:12 AM, Roman Joost wrote:
I could and the patch provided by that bug adds a custom
'property-changed' signal. Sven and Mitch thought, if I inherit from
XMPModel, I wouldn't really need the 'property-changed' signal, because
I'd be able to control the 'property-changed' signal. That is true, but
maybe I wasn't clear enough saying, that I want to distinguish if a
schema or a property changed by using different signals.
Inheriting XMPModel from GtkTreeStore (that's what you meant, right?)
Yes - that's what I ment. Sorry for the misunderstanding.
does not change the fact that it would be nice to have a
'property-changed' signal as a convenience if you have the need to
listen property changes
So ... I'm just wondering. If I like to use two signals for the
XMPModel, does it still make sense to inherit from GtkTreeStore? I mean,
I can't currently see any benefits if I inherit from GtkTreeStore.
My current model looks like this:
struct _XMPModel
{
GtkTreeStore parent_instance;
GSList *custom_schemas;
GSList *custom_properties;
XMPSchema*cached_schema;
GtkTreeIter cached_schema_iter;
};
The model before inherited from GObject and had another member, which
was the GtkTreeStore.
Cheers,
--
Roman Joost
www: http://www.romanofski.de
email: romanof...@gimp.org
signature.asc
Description: Digital signature
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] XMPModel and custom signals
On 08/02/2009 01:50 PM, Roman Joost wrote: does not change the fact that it would be nice to have a 'property-changed' signal as a convenience if you have the need to listen property changes So ... I'm just wondering. If I like to use two signals for the XMPModel, does it still make sense to inherit from GtkTreeStore? I mean, I can't currently see any benefits if I inherit from GtkTreeStore. In general, aggregation is preferable to inheritance because the former results in more dynamic code with less assumptions. If you think aggregation makes more sense than inheritance in this case, then I'd say go ahead and use aggregation, i.e. have a GtkTreeStore as an instance member in XMPModel / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 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. -- Emil ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Locking a layer
_ Tienes BlackBerry, obtén Messenger y Hotmail - Clic Aquí http://www.windowsliveentublackberry.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] locking a layer
_ Mes de la amistad… disfrútalo con MSN Amor y Amistad http://match.latam.msn.com/channel/index.aspx?trackingid=1056244 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 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 mart...@src.gnome.org 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 -- My GIMP Blog: http://www.chromecode.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Does Hue, Saturation, Value layer modes need HSV? How about CIE LCH instead?
On Mon, Aug 3, 2009 at 5:13 AM, Martin Nordholts ense...@gmail.com 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 mart...@src.gnome.org 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
