Re: babl roadmap: How do you know which images are sRGB images?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Tue, Oct 14, 2014 at 11:20 AM, Elle Stone
<ellestone@xxxxxxxxxxxxxxxxxxxx> wrote:
> On 10/13/2014 06:36 PM, Elle Stone wrote:
>> How do you plan to tell when an image is an sRGB image and when it's not
>> an sRGB image?
> The roadmap specifies 24 different formats for sRGB images and 24 additional
> formats for non-sRGB images.

Incorrect, foo and bar a metasyntactical variables; which have a
meaning in software development. They are placeholders, babl doesn't
know, and shouldn't care what these names/concepts are, the only
formats specified in the roadmap are synonyms for the already existing
color formats using the sRGB prefix. The ones with foo and bar
prefixes are illustrative place-holders, GEGL and other things using
babl. Have to choose what different named families of pixel formats
mean for their workflows.

> Presumably the 24 additional formats for non-sRGB images allow GEGL to
> request, as needed, a conversion of the RGB data from being encoded using
> sRGB primaries to being encoded using "User_RGB" primaries and vice versa.

There isn't 24 additional formats, but N*12 additional formats, N
depending on our needs in GEGL, foo and bar might have been replaced
with, "compositing", "chromaticity", "target" or other registered
classes of RGB for the editing session/pipeline.

> Given the 24 additional formats for non-sRGB images, it seems pretty
> important to be able to detect when the user opens an sRGB image and when
> the user opens an image that's in some other RGB working space.

> So again, upon opening an image, how do you plan to detect whether the image
> is an sRGB image or not?

> Will you compare MD5 checksums?
> Will you consult the profile descriptions?
> Will you examine the profile colorants and TRCs?

Deciding on this is outside the scope of babls roadmap, since this is
something that would have to happen in GEGL or other things using
babl. Most likely examination of profile colorants/TRCs since that is
what ICC or other color profile meta-data aware image loaders needs to
provide down to babl anyways. How the loading code does this; and
whether the behavior is configurable in GEGL (without knowing whether
it will be end up configurable in GIMP for that reason). In many
circumstances it is desirable to to treat almost sRGB as sRGB and
consider deviance from the real standard a mistake in labeling; for
instance if it is a low bitdepth image containing dithering - at other
times assuming that the slight off profile has been applied as is
earlier in the production pipeline might be desirable.

gegl-developer-list mailing list
List address:    gegl-developer-list@xxxxxxxxx
List membership:

[Index of Archives]     [Yosemite News]     [Yosemite Photos]     [gtk]     [GIMP Users]     [KDE]     [Gimp's Home]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux