On Tue, Oct 14, 2014 at 11:20 AM, Elle Stone 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.

/Ø

Elle,

"It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat."
- Theodore Roosevelt

Time for you to stop making vaguely patronising remarks and make an actionable suggestion, or leave this.

Hugs and positivity, Ed

-----Original Message----- From: Elle Stone
Sent: Friday, October 17, 2014 4:43 PM Cc: gegl-developer-list ; Gimp-developer Subject: Re: [Gimp-developer] [Gegl-developer] babl roadmap: How do you know which images are sRGB images?

On 10/14/2014 07:16 AM, Øyvind Kolås wrote:

On Tue, Oct 14, 2014 at 11:20 AM, Elle Stone wrote:

On 10/13/2014 06:36 PM, Elle Stone wrote: 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?

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.

You did pick the only plausible answer: check the colorants and TRCs.

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.

For most users, for most purposes, you as developer can probably decide for the user that "slight off" means "close enough". The trouble is you don't know whether "slight off" is a mistake or intentional.

The profile maker might have used something other than Bradford adaptation to make the profile. This is allowed by the ICC specs, and would result in slightly different colorants.

The artist might be fully aware that the profile is not exactly like the GIMP built-in profile, and nonetheless intend to use the embedded sRGB profile instead of the GIMP built-in sRGB profile. Perhaps the existing gray axis needs to be preserved.

And so on. You think it's OK to second-guess and decide for the artist what happens to the artist's RGB data. But it's really not OK.

Elle Stone