On 2/3/07, Andrew Pendleton wrote:

* In the operation, I convert from 32-bit float rgba to HSL, do the operations, and convert back again. It occured to me, later, that perhaps this was something that should be done as a colorspace conversion in babl, instead, though it doesn't look like HSL is a currently supported babl colorspace. Is that correct, or is this legit?

It is correct that HSL is currently not a supported color space in babl. HSL is in my opinion most useful as a color picker/GUI color model and not a color space you necessarily want to do many adjustments in. Thus if there is going to be operations in GEGL working in HSL I find it likely that they at least initially will have to carry the conversion code themselves to avoid cluttering up babl with mostly useless color models.

* Are adjustments to lightness and saturation usually multiplicative? I started out having all of the adjustments be additive, and while that worked for hue, it gave results for lightness and saturation that were markedly different from those of the current Gimp. At present, they add the factor times the current value, and that seems to approximate the Gimp's behavior for saturation, though not for lightness. Perhaps I just don't have the minimum and maximum values of my ranges set appropriately? I may just dig into the current Gimp code and see how they do it...

Adjustments to saturation in HSL would be multiplicative, for the hue you would be rotating the color data when doing addition so this is correct as well. For the lightness you will probably want both multiplication (contrast) as well as addition (brightness). Read up on the geometry of the color model to see how the changes affects colors.

* Is there a standard for coding style in GEGL? It seems that two-space indents are common, but other than that, other practices don't seem entirely consistent, and I'd like to format things appropriately, as I go, if possible.

The coding style GEGL is supposed to follow is GNU coding style which is also the coding style used in GIMP and GTK. The only thing you seem to get wrong is that the start braces after an if/else should also be indented two spaces.

* Is there a TODO, somewhere? I saw that one existed in earlier CVS iterations, but it seems to be gone from current SVN. I picked HSL because I figured it wouldn't be too hard, and there wasn't one, but being able to spend time on things that actually need doing would be good.

Bugzilla is used for issue tracking. I do not see the operation you have coded as a very important operation to have. The functionality is mostly provided by a combination of either brightness-contrast/levels + whitebalance. As the whitebalance operation provides saturation adjustment as well as better means to correct photographs for color casts. It needs a proper GUI to be useful though.

The API to write new custom plug-ins is also not considered stable it will change a bit, adding many more operations that needs to be kept up to date is not desirable. If you want to write plug-ins the ones in the SVG 1.1 filter specification are amongst the ones desired.

/Øyvind K.

Hi,

On Sat, 2007-02-03 at 16:12 +0100, Øyvind Kolås wrote:

It is correct that HSL is currently not a supported color space in babl. HSL is in my opinion most useful as a color picker/GUI color model and not a color space you necessarily want to do many adjustments in. Thus if there is going to be operations in GEGL working in HSL I find it likely that they at least initially will have to carry the conversion code themselves to avoid cluttering up babl with mostly useless color models.

HSL layer modes have been requested for GIMP (see bug #401754 and also bug #404378 for another request that deals with layer and paint modes). It might make sense to consider adding these to babl/gegl.

Sven

On 2/4/07, Sven Neumann wrote:

HSL layer modes have been requested for GIMP (see bug #401754 and also bug #404378 for another request that deals with layer and paint modes). It might make sense to consider adding these to babl/gegl.

I'd rather add CIE Luv and use that in place of HSV/HSL. Adding HSV/HSL to babl should be a matter of writing an extension, but the slightly more perceptual CIE color space is probably more desirable. Ideally all possible candidate color spaces will be possible to use but implementing the saner ones first should be a priority.

GEGL currently contains a large enough amount of plug-ins that changes to the API they use take time. It is expected that this API will go through considerable refactoring and thus getting a lot of new plug-ins into the main distribution is not desirable as it will make the refactoring take more time. This is part of the reason I want to be conservative with which plug-ins are added.

/Øyvind K.

On 2/5/07, Loo Barry wrote:

HSL/HSB has many unsung uses in masking/selections; plus, it/they allow(s) more oppurtunities for creative channel operations. It's sorely missed in newer versions of photoshop and the lack of a HS_ color space is the reason why many of us are forced to use 20th century software.

The color space I propose to use CIE Luv, is also what you would consider a "HS_" color space, except for that fact that it is more perceptually uniform and better engineered. CIE Luv > HSL > HSV. CIE Luv is like CIE Lab, except that instead of having an opponent color model like CIE Lab/Y'CbCr it provides a hue angle and a saturation like HS_.

I'm arguing that I do not want HSV in the base distribution of babl, I probably do not want HSL either but I can agree to put CIE Luv in there. If GIMP will have a need to support it's confusing HSV legacy it will probably have to do so by providing it's own babl extensions to do so that do not live in the babl tree, as well as it's own GEGL plug-in operations that do not live in the GEGL tree.

/Øyvind K.