On 2/3/07, Andrew Pendleton <abpend@xxxxxxxxx> 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.
--
«The future is already here. It's just not very evenly distributed»
-- William Gibson
http://pippin.gimp.org/ http://ffii.org/
_______________________________________________
Gegl-developer mailing list
Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
