You are correct in the sense that *right now*, most of the babl color
spaces are based on the sRGB chromaticities. There is nothing
preventing us from adding different color spaces in the future,
including ProPhoto RGB.
> And if the operation is better done in in some other color space *model*,
> not RGB but rather perhaps CIELAB or HSL or whatever, then the conversion is
> now and will always be from *sRGB* to CIELAB, HSL or whatever, yes?
No, not always. Gimp already has the option of storing your image in a
linear or perceptual gray color space, as well as different indexed
formats. As above, new formats can be added easily. Can I ask: what
difference does it make? If I convert an image from ProPhoto to
CIELAB, or if I convert from sRGB to CIELAB, I will get the same
result. The gegl operation doesn't care how the data is stored; it
only cares what format it receives the data in.
On Sun, Apr 13, 2014 at 8:08 AM, Elle Stone
<ellestone@xxxxxxxxxxxxxxxxxxxx> wrote:
> On 04/13/2014 06:41 AM, pippin@xxxxxxxx wrote:
>>
>> On Sun, Apr 13, 2014 at 06:18:08AM -0400, Elle Stone wrote:
>>>
>>> In the strongly color-managed world of BABL and GEGL, the only *RGB*
>>> color space/working is *s*RGB, either the linear gamma/light sRGB or
>>> the more perceptually uniform regular sRGB with its not quite
>>> gamma=2.2 TRC.
>>
>>
>> There is no linear gamma *or* perceptually uniform choice at import. There
>> is a
>> conversion to one of the babl-managed pixel formats; and after that GEGL
>> operations are free to convert between any of the unbounded babl formats.
>
>
> I didn't mean to imply that there was a choice of which TRC to choose upon
> import. The plan seems to be that when GIMP 2.10 is released the image will
> be converted from its source color space to a color space with the sRGB
> chromaticities.
>
> Whether that sRGB color space is actually linear gamma sRGB or sRGB with the
> regular sRGB tone reproduction curve is a separate question. You are saying
> that which TRC is used depends on the operation in questions. For example
> currently heal and drawing a gradient are done using the sRGB TRC. And
> Scale, Gaussian blur, and Unsharp Mask are done using the linear gamma TRC.
> Yes?
>
> The point is that when GIMP 2.10 is released, regardless of what happens to
> the TRC upon import, the *chromaticities* used for all further processing
> will be the sRGB chromaticities, NOT the chromaticities of the source color
> space. This point has been confirmed several times.
>
>> GIMP is making things more confusing by letting an arbitrary extra
>> parameter
>> change the behavior of compositing ops; this "feature" is something I
>> consider
>> a bug, it shouls also be considered bugs to do operation in linear space
>> if the
>> algortihm of a GEGL op behaves incorrectly/really unexpectedly unless it
>> works
>> in a more perceptual space.
>
>
> OK, so in the interests of consistency, the limited current choice between
> allowing an operation to happen in the linear gamma sRGB color space vs the
> more perceptually uniform regular sRGB color space should be eliminated,
> yes? You consider this UI user choice to be a bug, yes?
>
>>> I've asked this question of what is actually meant by "color
>>> space/working space" in the world of BABL and GEGL twice before now,
>>> and no one has answered. But it's a pretty important point, so I'm
>>> asking again.
>>>
>>> Thanking you in advance for confirmation/clarification of what
>>> "color space/working space" means when discussing *BABL/GEGL* color
>>> spaces/working space,
>>
>>
>> Not sure if this is a clarification; I do not know what you mean by the
>> terms
>> either and can only tell you what the intended architecture of GEGL is
>
>
>
>>> sRGB converted to CIELAB.
>>> sRGB converted to HSL.
>>> sRGB converted to HSV.
>>> sRGB converted to CMY(K).
>>> sRGB converted to Gray.
>>> sRGB converted to YCbCr.
>>> sRGB converted to some other model of color space, such as XYZ or
>>> CIELUV, for which code might be written at some point in the future.
>
>
>
> In the folder babl/extensions, see ycbcr.c, naive-CMYK.c, grey.c, HSV.c,
> HSL.c, CIE.c. These conversion are between the sRGB RGB color space and
> various other color space models, namely CIELAB, HSL, HSV, CMY(k), Gray, and
> YCbCr.
>
> The sRGB TRC is assumed in many places in the BABL code. To see what I mean,
> do a command line search in the babl source code folder:
>
> find -name "*.c" -or -name "*.h" | xargs grep -H "gamma_2_2" {} \;
>
> The sRGB chromaticities are assumed in various places in BABL, GEGL, and
> GIMP. Do a search for the word LUMINANCE, although some places have the
> values hard-coded.
>
>
>>
>>> The key point is that the chromaticities of the *RGB* color space, that
>>> might be converted to some other *model* of color space, are *always*
>>> the *s*RGB chromaticities.
>
>
> There is no provision for converting from some other RGB color space to
> these other color models. The only provision is for converting from sRGB to
> these other color space models.
>
>
>
> On 04/12/2014 06:45 PM, Øyvind Kolås wrote:>
>>
>> You seem to be under the impression that all processing whatever the
>> operation is done going to happen in one color space/pixel format a
>> "working space". In a GEGL processing world; it is the individual
>> operations that have working spaces; there is no global working space
>> that things happen in. (NB: having gamma toggles in blending modes of
>> GIMP is according to this model making things confusing, compositing
>> in different color spaces should be _different_operations_).
>>
>>
> I do think I understand what you are saying. Gaussian blur, Unsharp Mask,
> and Scale are examples of operations that give technically incorrect results
> when done in a nonlinear RGB color space. So you are saying GEGL/GIMP
> shouldn't allow the choice to perform these operations in the regular sRGB
> color space with its almost perceptually uniform TRC, yes? Rather they
> should only be done in linear gamma space, which is actually how it works
> right now.
>
> And if the operation is better done in in some other color space *model*,
> not RGB but rather perhaps CIELAB or HSL or whatever, then the conversion is
> now and will always be from *sRGB* to CIELAB, HSL or whatever, yes?
>
>
> Elle
>
> _______________________________________________
> gimp-developer-list mailing list
> List address: gimp-developer-list@xxxxxxxxx
> List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> List archives: https://mail.gnome.org/archives/gimp-developer-list
_______________________________________________
gimp-developer-list mailing list
List address: gimp-developer-list@xxxxxxxxx
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list
