RSS/Atom feed Twitter
Site is read-only, email is disabled

babl roadmap

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

36 of 36 messages available
Toggle history

Please log in to manage your subscriptions.

babl roadmap Elle Stone 12 Oct 18:27
  babl roadmap Elle Stone 13 Oct 08:34
   babl roadmap Elle Stone 13 Oct 18:19
    babl roadmap Øyvind Kolås 13 Oct 19:25
     babl roadmap Elle Stone 13 Oct 22:34
      babl roadmap Øyvind Kolås 14 Oct 10:54
       babl roadmap Elle Stone 14 Oct 11:34
        babl roadmap Øyvind Kolås 14 Oct 11:52
         babl roadmap Elle Stone 14 Oct 12:14
          babl roadmap Thorsten Stettin 14 Oct 12:41
           babl roadmap Simon Budig 14 Oct 13:04
            babl roadmap Christopher Curtis 14 Oct 13:36
             babl roadmap Simon Budig 14 Oct 13:54
              babl roadmap Nicolas Robidoux 14 Oct 14:14
              babl roadmap Christopher Curtis 14 Oct 14:28
            babl roadmap Thorsten Stettin 14 Oct 13:58
             babl roadmap Jehan Pagès 14 Oct 18:18
              babl roadmap scl 14 Oct 19:06
               babl roadmap Burnell West 15 Oct 14:25
          babl roadmap Simon Budig 14 Oct 12:50
           babl roadmap Elle Stone 15 Oct 12:11
            babl roadmap Øyvind Kolås 15 Oct 12:30
             babl roadmap Elle Stone 15 Oct 14:19
              babl roadmap Jon Nordby 15 Oct 17:27
               babl roadmap Michael Henning 15 Oct 17:58
                babl roadmap Elle Stone 15 Oct 19:37
                 babl roadmap Tobias Ellinghaus 15 Oct 20:19
             babl roadmap Elle Stone 15 Oct 16:39
              babl roadmap Simon Budig 15 Oct 17:46
               babl roadmap Elle Stone 16 Oct 16:52
                babl roadmap Øyvind Kolås 16 Oct 19:37
                 babl roadmap Jon Nordby 16 Oct 22:49
                  babl roadmap Øyvind Kolås 16 Oct 23:23
                 babl roadmap Elle Stone 17 Oct 10:01
                  babl roadmap Øyvind Kolås 17 Oct 10:08
           babl roadmap Elle Stone 17 Oct 10:04
Elle Stone
2014-10-12 18:27:44 UTC (over 9 years ago)

babl roadmap

The planned architecture as outline in babl/docs/roadmap.txt will likely collapse under its own weight.

But if the devs are determined to pursue this course to the bitter end, here are some suggestions regarding "white_reference":

//begin quote . . . permitting at least linear formats with other chromaticities is highly desirable, this will be fixed by allowing to specify named RGB spaces, possibly like this:

void babl_define_named_rgb_space ( Babl *babl,
const char *name,
double red_xyz[3],
double blue_xyz[3],
double green_xyz[3],
int white_reference, /* could be _XYZ[3] instead of d50/d65/d60; but this is likely sufficient */
double trc_gamma /* makes sense to have it even if not initially used */
);//end quote

Short version:

You might want to specify white_reference using XYZ[3] instead of using "int".

You probably want *two* variables: 1. the color space specifications reference white. 2. the ICC profile illuminant.

The variable names might be "white_reference" and "profile_illuminant".

The D50 profile illuminant tag that's in LCSM and ArgyllCMS profiles has these XYZ values: (0.96420288, 1.00000000, 0.82490540).

The XYZ values for the D65 sRGB color space specification reference white are (0.950455927, 1.000000000, 1.089057751). These values are converted from xyY as given in the sRGB color space spec.

Long version:

1. Different profile specifications, standards bodies, etc. specify slightly different XYZ/xyY values for D50, D65, etc. And sometimes CMMs and profile makers make up their own D65 values for no apparent reason (http://ninedegreesbelow.com/photography/linux-icc-profiles.html#variants - scroll down to the table labelled "Selected D50 and D65 profile white point xyY values").

2. The ICC spec D50 illuminant values are (0.9642, 1.0, 0.8249). These aren't "rounded to four places" values. These are the actual values given in the ICC spec.

3. ICC profile illuminant XYZ values as found in actual profiles are hexadecimal-rounded. When converted back to decimal, the actual D50 illuminant XYZ values from an LCMS or ArgyllCMS profile are: (0.96420288, 1.00000000, 0.82490540).

4. The next release of the ICC specifications likely will allow illuminants other than D50. So assuming LCMS also will support this new functionality, at some point the function "babl_define_named_rgb_space" will need to directly retrieve the profile illuminant XYZ values.

5. In an ICC profile, the original color space XYZ values have been adapted *from* the color space reference white *to* the ICC profile illuminant. See
http://ninedegreesbelow.com/photography/srgb-color-space-to-profile.html

6. In an ICC profile color-managed image editor, you use relative colorimetric conversions between RGB working spaces, so the original color space reference white (for example, D65 for sRGB) is completely irrelevant.

With respect,
Elle Stone

http://ninedegreesbelow.com
Color management and free/libre photography
Elle Stone
2014-10-13 08:34:27 UTC (over 9 years ago)

babl roadmap

The planned architecture as outline in babl/docs/roadmap.txt will likely collapse under its own weight.

If the devs are determined to pursue this course to the bitter end, here are some considerations regarding encoding "trc_gamma" as "double" (you really can't do this):

//begin quote from the babl roadmap

double trc_gamma /* makes sense to have it even if not initially used */
);//end quote

ICC RGB working space profile Tone Reproduction Curve information ("TRC") can't be held in one "double" variable unless the TRC really is a true gamma TRC.

Some ICC RGB working space profiles have true gamma TRCs.

Some ICC RGB working spaces have point curve TRCs specified by varying numbers of points.

Some ICC RGB working spaces have TRCs that are specified using parametric curves, which take five parameters.

Given that not all profile TRC information can be stored in one "double" variable, you might consider removing the trc_gamma variable from "babl_define_named_rgb_space".

A proper TRC retrieving function could be written later, if/when you want to make use of the information.

With respect, Elle Stone

http://ninedegreesbelow.com
Color management and free/libre photography
Elle Stone
2014-10-13 18:19:51 UTC (over 9 years ago)

babl roadmap

The "sRGB as PCS" architecture outline in babl/docs/roadmap.txt will likely collapse under its own weight. The roadmap should be amended to reflect a more accurate assessment of the amount of work the planned architecture will entail.

The babl roadmap says:

"Babl currently only supports formats using the sRGB primaries, quite a few editing operations including gamma adjustments and multiply compositing relies on the chromaticities of the space used, permitting at least linear formats with other chromaticities is highly desirable"

As the purpose of the roadmap seems to be guiding future development, the list of editing operations that rely on the chromaticities of the RGB working space needs to be expanded. The following list is not complete, but it's a start:

Channel data used as a blending layer Channel data used for making selections

Colors/Alien Map HSL Colors/Alien Map RGB
Colors/Auto stretch contrast
Colors/Auto stretch contrast HSV
Colors/Channel Mixer (try Margulis' "enhance green" formula) Colors/Desaturate average
Colors/Desaturate lightness
Colors/Mono Mixer (except Luminosity-based B&W conversions) Colors/Posterize
Colors/Threshold
Colors/Levels Gamma slider operations Colors/Levels Red, Green, and Blue Input/Output sliders Colors/Levels "Auto Pick" (used for white balancing images)

Filters/Artistic/Cartoon Filters/Edge Detect/Sobel
Filters/Enhance/Red Eye Removal
Filters/Noise/HSV Noise
Filters/Noise/RGB Noise
Filters/Artistic/Soft glow
Filters/Artistic/Vignette (any color except gray, white, black)

Layer blend Mode/Burn Layer blend Mode/Color
Layer blend Mode/Darken only
Layer blend Mode/Difference
Layer blend Mode/Divide
Layer blend Mode/Dodge
Layer blend Mode/Hard light
Layer blend Mode/Hue
Layer blend Mode/Lighten only
Layer blend Mode/Multiply
Layer blend Mode/Overlay
Layer blend Mode/Screen
Layer blend Mode/Saturation
Layer blend Mode/Value

In addition, Paint tools depend on the working space chromaticities when using the following blend Modes: Burn, Color, Darken only, Difference, Divide, Dodge, Hard light, Hue, Lighten only, Multiply, Overlay, Saturation, Screen, Soft light, Value.

The babl roadmap should be amended to include all of the above-listed operations as requiring special-casing in the "sRGB as PCS" architecture.

More than half of the approximately 85 operations that I did check are chromaticity-dependent when performed on linear RGB data. Someone should check all editing operations. You can skip all strictly ADD/SUBTRACT-based operations, including scaling and gaussian blurs.

The roadmap says "permitting at least linear formats with other chromaticities is highly desirable". It is unclear why "permitting" should be limited to "linear formats". All of the operations listed above depend on the working space chromaticities, regardless of whether the RGB values are linear or perceptually uniform.

Indeed, some (and probably many) operations, that work just fine on linear unbounded sRGB values, are *very* dependent on the chromaticities when performed on perceptually uniform RGB values (for example drawing a gradient).

Someone should check all editing operations for perceptually encoded RGB to figure out which operations depend on the chromaticities, and then add these operations to the list of operations that need to be special-cased in the planned "sRGB as PCS" architecture.

With respect, Elle Stone

http://ninedegreesbelow.com
Color management and free/libre photography
Øyvind Kolås
2014-10-13 19:25:28 UTC (over 9 years ago)

babl roadmap

On Mon, Oct 13, 2014 at 8:19 PM, Elle Stone wrote:

The "sRGB as PCS" architecture outline in babl/docs/roadmap.txt will likely collapse under its own weight. The roadmap should be amended to reflect a more accurate assessment of the amount of work the planned architecture will entail.

The babl roadmap says:

"Babl currently only supports formats using the sRGB primaries, quite a few editing operations including gamma adjustments and multiply compositing relies on the chromaticities of the space used, permitting at least linear formats with other chromaticities is highly desirable"

As the purpose of the roadmap seems to be guiding future development, the list of editing operations that rely on the chromaticities of the RGB working space needs to be expanded. The following list is not complete, but it's a start:

The place for this would be in the GIMP wiki; where the state of migration from old type gimp plug-ins to GEGL ops, as well as other tracking state of ops are maintained. http://wiki.gimp.org/wiki/Hacking:Porting_filters_to_GEGL

The roadmap says "permitting at least linear formats with other chromaticities is highly desirable". It is unclear why "permitting" should be limited to "linear formats". All of the operations listed above depend on the working space chromaticities, regardless of whether the RGB values are linear or perceptually uniform.

This has to do with which capabilities one chooses to implement early, since it would bring a functional system, the non sRGB TRC are nice to have but not as fundamental as custom chromaticities. Not having custom TRCs for custom formats; means that those formats would be using the sRGB TRC until such support would be added.

Indeed, some (and probably many) operations, that work just fine on linear unbounded sRGB values, are *very* dependent on the chromaticities when performed on perceptually uniform RGB values (for example drawing a gradient).

Someone should check all editing operations for perceptually encoded RGB to figure out which operations depend on the chromaticities, and then add these operations to the list of operations that need to be special-cased in the planned "sRGB as PCS" architecture.

The per-op working pixel representation are part of GEGLs design, thus it isn't really special casing - but specifying.

Elle Stone
2014-10-13 22:34:15 UTC (over 9 years ago)

babl roadmap

On 10/13/2014 03:25 PM, Øyvind Kolås wrote:

On Mon, Oct 13, 2014 at 8:19 PM, Elle Stone wrote:

As the purpose of the roadmap seems to be guiding future development, the list of editing operations that rely on the chromaticities of the RGB working space needs to be expanded. The following list is not complete, but it's a start:

The place for this would be in the GIMP wiki; where the state of migration from old type gimp plug-ins to GEGL ops, as well as other tracking state of ops are maintained. http://wiki.gimp.org/wiki/Hacking:Porting_filters_to_GEGL

It's OK with me if you put the information in the GIMP wiki. But if you attribute the information to me, please include the disclaimer that I think your architecture will eventually collapse under its own weight.

Someone should check all editing operations for perceptually encoded RGB to figure out which operations depend on the chromaticities, and then add these operations to the list of operations that need to be special-cased in the planned "sRGB as PCS" architecture.

The per-op working pixel representation are part of GEGLs design, thus it isn't really special casing - but specifying.

You designed an architecture around converting images to unbounded sRGB for editing.

After 6 months of trying to show you that your architecture has serious built-in problems, you finally believe me, or at least you believe Mansencal and Sayre. But you want to keep the architecture anyway.

So now all chromaticity-dependent editing operations will require a brand new "special "specifying"", unless the image is already an sRGB image.

If you didn't intend to convert all images to unbounded sRGB for editing, there wouldn't be any reason to "special "specify"" roughly half of all the editing operations that you offer through the GIMP UI.

With respect, Elle Stone
--
Some operations that require "special "specifiying"", assuming linear encoding:
Channel data used as a blending layer Channel data used for making selections Colors/Alien Map HSL
Colors/Alien Map RGB
Colors/Auto stretch contrast
Colors/Auto stretch contrast HSV
Colors/Channel Mixer (try Margulis' "enhance green" formula) Colors/Desaturate average
Colors/Desaturate lightness
Colors/Mono Mixer (except Luminosity-based B&W conversions) Colors/Posterize
Colors/Threshold
Colors/Levels Gamma slider operations Colors/Levels Red, Green, and Blue Input/Output sliders Colors/Levels "Auto Pick" (used for white balancing images) Filters/Artistic/Cartoon
Filters/Edge Detect/Sobel
Filters/Enhance/Red Eye Removal
Filters/Noise/HSV Noise
Filters/Noise/RGB Noise
Filters/Artistic/Soft glow
Filters/Artistic/Vignette (any color except gray, white, black) Layer blend Mode/Burn
Layer blend Mode/Color
Layer blend Mode/Darken only
Layer blend Mode/Difference
Layer blend Mode/Divide
Layer blend Mode/Dodge
Layer blend Mode/Hard light
Layer blend Mode/Hue
Layer blend Mode/Lighten only
Layer blend Mode/Multiply
Layer blend Mode/Overlay
Layer blend Mode/Screen
Layer blend Mode/Saturation
Layer blend Mode/Value
Paint tools depend on the working space chromaticities when using the following blend Modes: Burn, Color, Darken only, Difference, Divide, Dodge, Hard light, Hue, Lighten only, Multiply, Overlay, Saturation, Screen, Soft light, Value.

Øyvind Kolås
2014-10-14 10:54:52 UTC (over 9 years ago)

babl roadmap

On Tue, Oct 14, 2014 at 12:34 AM, Elle Stone wrote:

You designed an architecture around converting images to unbounded sRGB for editing.

After 6 months of trying to show you that your architecture has serious built-in problems, you finally believe me, or at least you believe Mansencal and Sayre. But you want to keep the architecture anyway.

We've acknowledged that chromaticities matter for more than the last half year - and proposed to extend the architecture in ways that doesn't break other parts of the architecture. We change what we have, and avoid fixing what isn'r broken - while trying to address short-coming like you've pointed out.

So now all chromaticity-dependent editing operations will require a brand new "special "specifying"", unless the image is already an sRGB image.

If you didn't intend to convert all images to unbounded sRGB for editing, there wouldn't be any reason to "special "specify"" roughly half of all the editing operations that you offer through the GIMP UI.

Just like in an ICC based workflow images are converted to unbounded XYZ for editing? (they are not) The PCS used by a CMS is an implementation detail; where choices might have been XYZ, linear sRGB or some other linear RGB; of the preceding linear sRGB has nicer properties than any of the others.

Elle Stone
2014-10-14 11:34:16 UTC (over 9 years ago)

babl roadmap

On 10/14/2014 06:54 AM, Øyvind Kolås wrote:

So now all chromaticity-dependent editing operations will require a brand new "special "specifying"", unless the image is already an sRGB image.

If you didn't intend to convert all images to unbounded sRGB for editing, there wouldn't be any reason to "special "specify"" roughly half of all the editing operations that you offer through the GIMP UI.

Just like in an ICC based workflow images are converted to unbounded XYZ for editing? (they are not)

My apologies, I don't have a clue what you mean by what you just said.

But no, XYZ isn't a good color space for image editing, if that is what you are asking.

The PCS used by a CMS is an
implementation detail; where choices might have been XYZ, linear sRGB or some other linear RGB; of the preceding linear sRGB has nicer properties than any of the others.

The above sentence confuses concepts: The babl architecture might require that images to be converted to and from unbounded linear gamma sRGB. That doesn't mean babl is a CMS. And it doesn't mean unbounded linear gamma sRGB has been turned into a PCS.

To convert images to and from unbounded linear gamma sRGB, you MUST pass through XYZ. XYZ is the PCS.

Let's cut to the chase:

Are you planning on converting non-sRGB images to unbounded linear gamma sRGB? Yes or no?

If yes, are you intending that at least some editing will be done on the image while it's encoded using sRGB primaries? Yes or no?

With respect, Elle Stone

Øyvind Kolås
2014-10-14 11:52:40 UTC (over 9 years ago)

babl roadmap

On Tue, Oct 14, 2014 at 1:34 PM, Elle Stone wrote:

The above sentence confuses concepts: The babl architecture might require that images to be converted to and from unbounded linear gamma sRGB. That doesn't mean babl is a CMS. And it doesn't mean unbounded linear gamma sRGB has been turned into a PCS.

Babls role in the GEGL and thus GIMP architecture is to be the internal CMS; this remains unchanged since babl was split out of a non-linear video editor/compositing system.

To convert images to and from unbounded linear gamma sRGB, you MUST pass through XYZ. XYZ is the PCS.

I remind you that linear RGB spaces are a single matrix multiplication away from other linear RGB spaces and XYZ.

Let's cut to the chase:

Are you planning on converting non-sRGB images to unbounded linear gamma sRGB? Yes or no?

Foo or bar? Do you have any idea what "implementation detail" means?

/pippin

Elle Stone
2014-10-14 12:14:19 UTC (over 9 years ago)

babl roadmap

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

On Tue, Oct 14, 2014 at 1:34 PM, Elle Stone wrote:

To convert images to and from unbounded linear gamma sRGB, you MUST pass through XYZ. XYZ is the PCS.

I remind you that linear RGB spaces are a single matrix multiplication away from other linear RGB spaces and XYZ.

Matrix conversions between RGB working spaces can be concantenated. That concantenation goes through XYZ. It almost sounds like you want to obscure this fundamental distinction between XYZ and unbounded linear gamma sRGB.

Let's cut to the chase:

Are you planning on converting non-sRGB images to unbounded linear gamma sRGB? Yes or no?

Foo or bar? Do you have any idea what "implementation detail" means?

I do know what "implementation detail" means.

You didn't the question, so I'll try again:

Are you planning on converting non-sRGB images to unbounded linear gamma sRGB? Yes or no?

If yes, are you intending that at least some editing will be done on the image while it's encoded using sRGB primaries? Yes or no?

With respect, Elle Stone

Thorsten Stettin
2014-10-14 12:41:18 UTC (over 9 years ago)

babl roadmap

Hi, Elle,

with all due respect to you, I think you should contribute instead to babble.

Sorry for that

Best regards

Thorsten

Lao-Tse sagt: Nichtstun ist besser, als mit viel Mühe nichts zu schaffen.
Und er sagt auch: Ich habe drei Schätze, die ich hüte und hege.
Der eine ist die Liebe, der zweite ist die Genügsamkeit, der dritte ist die Demut.
Nur der Liebende ist mutig, nur der Genügsame ist großzügig, nur der Demütige ist fähig zu herrschen.
Simon Budig
2014-10-14 12:50:49 UTC (over 9 years ago)

babl roadmap

Elle Stone (ellestone@ninedegreesbelow.com) wrote:

On 10/14/2014 07:52 AM, yvind Kols wrote:

On Tue, Oct 14, 2014 at 1:34 PM, Elle Stone wrote:

To convert images to and from unbounded linear gamma sRGB, you MUST pass through XYZ. XYZ is the PCS.

I remind you that linear RGB spaces are a single matrix multiplication away from other linear RGB spaces and XYZ.

Matrix conversions between RGB working spaces can be concantenated. That concantenation goes through XYZ. It almost sounds like you want to obscure this fundamental distinction between XYZ and unbounded linear gamma sRGB.

for conversions between RGB working spaces there is no fundamental distinction between XYZ and unbounded linear gamma sRGB.

In mathematical terms both of these span up a three dimensional vector space (describing color) and the only difference is that they use different basis vectors.

You can *easily* describe conversions between different RGB primaries with ulgsRGB as the connecting space (completely replacing XYZ). You would get a different set of transformation matrices of course.

XYZ is something that has a special role for all of the non-RGB color spaces Lab, xyY, Luv etc, as well as operations like chromatic adaptation. Hence it makes sense to use it also as the connecting space for the different RGB primaries.

Are you planning on converting non-sRGB images to unbounded linear gamma sRGB? Yes or no?

For pixel storage we will use whatever fits our needs, it does not make sense at this point to specify this.

This might be a Lab-buffer with a cache in front of it that has the pixels converted to sRGB. Or a Adobe-RGB-Buffer without a cache. Or unbounded linear gamma sRGB. Or whatever.

The important thing is, that gegl/babl provides the means to access these data in whatever format is needed by the operation that is happening. A brightness-invert function might request the data in Lab, do the inversion on the L channel and feed the results back as Lab to the gegl/babl infrastructure, which will process it to provide the next operation in the graph with the input format the next operation needs.

If yes, are you intending that at least some editing will be done on the image while it's encoded using sRGB primaries? Yes or no?

That totally depends on the editing-operation in question and is orthogonal to the pixel memory storage format.

Bye, Simon

simon@budig.de              http://simon.budig.de/
Simon Budig
2014-10-14 13:04:32 UTC (over 9 years ago)

babl roadmap

Hi Thorsten.

Thorsten Stettin (thorsten.stettin@gmail.com) wrote:

with all due respect to you, I think you should contribute instead to babble.

If you perceive Elles texts as "babbling" it seems that this discussion is way over your head and you might want to consider staying out of it.

Thanks, Simon

simon@budig.de              http://simon.budig.de/
Christopher Curtis
2014-10-14 13:36:23 UTC (over 9 years ago)

babl roadmap

On Tue, Oct 14, 2014 at 9:04 AM, Simon Budig wrote:

If you perceive Elles texts as "babbling" it seems that this discussion is way over your head and you might want to consider staying out of it.

+1.

I'll admit that this discussion is way over my head, but as it seems to involve only two people would it be better handled over a phone call? It appears that there are some basic assumptions that aren't in alignment.

Chris

Simon Budig
2014-10-14 13:54:16 UTC (over 9 years ago)

babl roadmap

Christopher Curtis (ccurtis0@gmail.com) wrote:

I'll admit that this discussion is way over my head, but as it seems to involve only two people would it be better handled over a phone call? It appears that there are some basic assumptions that aren't in alignment.

While it certainly could be more concise, the discussion has helped me tremendously with my glimpse into gegl/babl. So while the misunderstandings might be easier to overcome within a phone call keeping the discussion on the list helps with potentially getting the concepts out there to more people.

That having said, meeting people in person *is* tremendously helpful and I'd like to extend pippins invitation to the LGM (next year in Toronto) to everybody who is interested in discussing these topics with e.g. pippin and me. There will be funds available to help bring people together.

Bye,
Simon

simon@budig.de              http://simon.budig.de/
Thorsten Stettin
2014-10-14 13:58:11 UTC (over 9 years ago)

babl roadmap

Am 14.10.2014 um 15:04 schrieb Simon Budig:

Hi Thorsten.

Thorsten Stettin (thorsten.stettin@gmail.com) wrote:

with all due respect to you, I think you should contribute instead to babble.

If you perceive Elles texts as "babbling" it seems that this discussion is way over your head and you might want to consider staying out of it.

Thanks, Simon

Ok, It pisses me off though. I didn't mean to hurt anybody. But we don't need any academic discussion. We need contribution.
Ok, I'm just a packager, sorry for that.

Cheers

Thorsten

Lao-Tse sagt: Nichtstun ist besser, als mit viel Mhe nichts zu schaffen.
Und er sagt auch: Ich habe drei Schtze, die ich hte und hege.
Der eine ist die Liebe, der zweite ist die Gengsamkeit, der dritte ist die Demut.
Nur der Liebende ist mutig, nur der Gengsame ist grozgig, nur der Demtige ist fhig zu herrschen.
Nicolas Robidoux
2014-10-14 14:14:29 UTC (over 9 years ago)

babl roadmap

+1

On 14 October 2014 15:54, Simon Budig wrote:

While it certainly could be more concise, the discussion has helped me tremendously with my glimpse into gegl/babl. So while the misunderstandings might be easier to overcome within a phone call keeping the discussion on the list helps with potentially getting the concepts out there to more people.

Christopher Curtis
2014-10-14 14:28:18 UTC (over 9 years ago)

babl roadmap

On Tue, Oct 14, 2014 at 9:54 AM, Simon Budig wrote:

While it certainly could be more concise, the discussion has helped me

tremendously with my glimpse into gegl/babl. So while the misunderstandings might be easier to overcome within a phone call keeping the discussion on the list helps with potentially getting the concepts out there to more people.

People seem to be getting frustrated and I don't think that helps anybody. It seems to me that realigning the conversation in a more appropriate medium would help to make the mailing list discussion more productive. A summary of the phone call would then either bring everyone back together, or continue the dispute on clearer terms.

Of course, folks are free to do whatever...

$0.02, Chris

Jehan Pagès
2014-10-14 18:18:20 UTC (over 9 years ago)

babl roadmap

Hi,

On Tue, Oct 14, 2014 at 3:58 PM, Thorsten Stettin wrote:

Am 14.10.2014 um 15:04 schrieb Simon Budig:

Hi Thorsten.

Thorsten Stettin (thorsten.stettin@gmail.com) wrote:

with all due respect to you, I think you should contribute instead to babble.

If you perceive Elles texts as "babbling" it seems that this discussion is way over your head and you might want to consider staying out of it.

Thanks, Simon

Ok, It pisses me off though. I didn't mean to hurt anybody. But we don't need any academic discussion.

Of course we do!
These kind of discussions are really helpful to understand things. Most of these are also over my head (though I wish I understood more of these!) but I am very grateful that they are done in the open! This is also part of what makes a sane Free Software.

Now of course, meeting people in LGM or elsewhere is also very good, but that should not prevent the results of these discussions to also be discussed publicly here.
Same if it were by phone, I would still always appreciate discussions to be summarized or continued on the mailing list.

We need contribution.

Seriously if you don't consider these extremely important contributions for GIMP (discussion on a good architecture for what is essentially the core of GIMP!), I wonder what will be! Of course "code" contributions *too* is nice, but these happen after the discussions in such cases.

Anyway please, this is the gimp-developer@ mailing list. If you don't like these discussions about improving the core of GIMP, maybe you are on the wrong list. Also you don't have to read them all! (there are a lot which I don't find interesting just by reading the title, I don't ask people to not write them!).
As long as everybody stays polite and remembers we are on a written medium (hence misunderstandings and annoyed feelings are easier to get; when that happens, just breath), please don't interrupt completely on-topic discussions.
Thanks.

Jehan

Ok, I'm just a packager, sorry for that.

Cheers

Thorsten

-- Lao-Tse sagt: Nichtstun ist besser, als mit viel Mühe nichts zu schaffen. Und er sagt auch: Ich habe drei Schätze, die ich hüte und hege. Der eine ist die Liebe, der zweite ist die Genügsamkeit, der dritte ist die Demut.
Nur der Liebende ist mutig, nur der Genügsame ist großzügig, nur der Demütige ist fähig zu herrschen.

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

scl
2014-10-14 19:06:20 UTC (over 9 years ago)

babl roadmap

Hi,

I fully agree with Jehan and think it's essential in a healthy software development process to scrutinize and review things. Especially the whole color management stuff is a topic that is not so clear to many of us and - with all my respect to Pippin - depending on a single expert's opinion is a risk in every project. It's natural for this topic that it is also academic. Academic work is the foundation for many things in the computer world, may the hands-on-people like it or not. Perhaps some other color management experts could join in and share their knowledge?
One thing could be improved from my point of view: the discussion is spread over the two lists gimp-developer and gegl-developer. As it is all mainly BABL- and GEGL-related it would be more helpful if the discussion took place on a single list. I propose the GEGL-developer list, because this catches both the GEGL-only devs as well as the GIMP devs.

Kind regards

Sven

Elle Stone
2014-10-15 12:11:20 UTC (over 9 years ago)

babl roadmap

On 10/14/2014 08:50 AM, Simon Budig wrote:

Elle Stone (ellestone@ninedegreesbelow.com) wrote:

Are you planning on converting non-sRGB images to unbounded linear gamma sRGB? Yes or no?

For pixel storage we will use whatever fits our needs, it does not make sense at this point to specify this.

Whether or not the roadmap calls for converting non-sRGB images to unbounded sRGB will determine what kind of code is written going forward.

In an ICC profile color-managed workflow, sRGB is just another RGB working space, requiring no special treatment.

The babl roadmap "sRGB as PCS/fooRGB" is a proposed solution to perceived problems. The problems for which "sRGB as PCS/fooRGB" might be a solution are things like:

*Reducing computing overhead for 8-bit sRGB image editing. *Accomodating legacy sRGB XCF files. *Accomodating legacy "sRGB only" file formats.

Solving legacy and 8-bit sRGB overhead problems does not require converting ICC profile color-managed images from fooRGB to unbounded sRGB.

If yes, are you intending that at least some editing will be done on the image while it's encoded using sRGB primaries? Yes or no?

That totally depends on the editing-operation in question

When the user opens a color-managed fooRGB image, for which *specific* editing operations will the image be converted to unbounded sRGB?

This isn't just an implementation detail. The answer to this question will determine the path for writing code going forward. To restate the question yet again:

Will all color-managed image editing be done using the user's chosen primaries, with absolutely no conversions to unbounded sRGB for image editing?

Or are the developers committing themselves to maintaining lists of which operations should be done using fooRGB primaries and which should be done using sRGB primaries?

With respect, Elle Stone

Øyvind Kolås
2014-10-15 12:30:39 UTC (over 9 years ago)

babl roadmap

On Wed, Oct 15, 2014 at 2:11 PM, Elle Stone

When the user opens a color-managed fooRGB image, for which *specific* editing operations will the image be converted to unbounded sRGB?

This isn't just an implementation detail. The answer to this question will determine the path for writing code going forward. To restate the question yet again:

If the user is putting a text-layer, which has been rendered using cairo and is in 8bit sRGB premultiplied alpha. The compositing of this with preceding data in the layer stack the babl-format of the output buffer of the over/normal compositing operation, as well as the data fetched from both buffer inputs - would likely be RaGaBaA float - if the two linear inputs differ.

At all points we know the CIE Lab or XYZ coordinates of all involved pixels – and we aim to do as few conversions as possible (never converting the actual data to either bablRGB or XYZ, even temporarily - unless requested.)

Will all color-managed image editing be done using the user's chosen primaries, with absolutely no conversions to unbounded sRGB for image editing?

Or are the developers committing themselves to maintaining lists of which operations should be done using fooRGB primaries and which should be done using sRGB primaries?

There is no plan to maintain lists in the end, this information would be self-contained within each individual operation, like whether the operation needs CIE Lab, pre-multiplied alpha or not or even an 16bit linear grayscale. This automatic data representation conversion is an inherent abstraction and property both of GeglBuffer and the services provided for op authors to make implementing consistently behaving operations easy.

Elle Stone
2014-10-15 14:19:04 UTC (over 9 years ago)

babl roadmap

On 10/15/2014 08:30 AM, Øyvind Kolås wrote:

On Wed, Oct 15, 2014 at 2:11 PM, Elle Stone wrote:

Will all color-managed image editing be done using the user's chosen primaries, with absolutely no conversions to unbounded sRGB for image editing?

Or are the developers committing themselves to maintaining lists of which operations should be done using fooRGB primaries and which should be done using sRGB primaries?

There is no plan to maintain lists in the end, this information would be self-contained within each individual operation,

If each individual operation will carry information about whether the operation should use fooRGB primaries or sRGB primaries, then at some point someone must compile a list for the devs to consult.

Unless you really mean to say:

*DevA working on Op1 decides whether to use fooRGB primaries or sRGB primaries for Op1.

*DevB working on Op2 decides whether to use fooRGB primaries or sRGB primaries for Op2.

*DevC can decide DevA and DevB were both wrong and change the code.

And so on.

Consider the following:

1. RGB editing operations performed on fooRGB images using fooRGB primaries are *always* correct.

2. More than half of all operations on linear RGB are chromaticity-dependent. Many more than half of all operations on perceptually encoded RGB are chromaticity-dependent. *All* of these operations WILL produce *wrong* results after the image is converted to unbounded sRGB.

So the developer choices are:

1. Either don't convert fooRGB images to unbounded sRGB for *any* RGB editing operations. Results will *always* be right.

2. Or else compile a list of all editing operations that "do work" and "don't work" in unbounded sRGB, and only convert the image to unbounded sRGB for the operations that "do work" in unbounded sRGB. And hope you get the list right, because you are messing with the user's RGB data for no good reason.

I will ask again:

For which specific RGB editing operations do you plan to convert the image from fooRGB to unbounded sRGB before performing the operation?

Either the answer is "None. For color-managed fooRGB images, all RGB operations will be done on data encoded using fooRGB primaries."

Or you are committing the devs to maintaining a formal or ad hoc list of operations on fooRGB data vs operations on unbounded sRGB data. And then you are committing the devs to writing per op code to implement entirely pointless conversions from fooRGB to unbounded sRGB and back again.

With respect, Elle Stone

Burnell West
2014-10-15 14:25:03 UTC (over 9 years ago)

babl roadmap

+ > 1
On Oct 14, 2014, at 9:06 PM, scl wrote:

Hi,

I fully agree with Jehan and think it's essential in a healthy software development process to scrutinize and review things. Especially the whole color management stuff is a topic that is not so clear to many of us and - with all my respect to Pippin - depending on a single expert's opinion is a risk in every project. It's natural for this topic that it is also academic. Academic work is the foundation for many things in the computer world, may the hands-on-people like it or not. Perhaps some other color management experts could join in and share their knowledge?
One thing could be improved from my point of view: the discussion is spread over the two lists gimp-developer and gegl-developer. As it is all mainly BABL- and GEGL-related it would be more helpful if the discussion took place on a single list. I propose the GEGL-developer list, because this catches both the GEGL-only devs as well as the GIMP devs.

Kind regards

Sven

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

Elle Stone
2014-10-15 16:39:53 UTC (over 9 years ago)

babl roadmap

On 10/15/2014 08:30 AM, Øyvind Kolås wrote:

On Wed, Oct 15, 2014 at 2:11 PM, Elle Stone

When the user opens a color-managed fooRGB image, for which *specific* editing operations will the image be converted to unbounded sRGB?

If the user is putting a text-layer, which has been rendered using cairo and is in 8bit sRGB premultiplied alpha. The compositing of this with preceding data in the layer stack the babl-format of the output buffer of the over/normal compositing operation, as well as the data fetched from both buffer inputs - would likely be RaGaBaA float - if the two linear inputs differ.

I'm not sure why your text-layer stack example is relevant to my very direct and still unanswered question.

But using GIMP 2.9, I put a text-layer over a color layer, first in a very large linear gamma (camera-based) color space, and then in a linear gamma color space with the sRGB primaries.

In both color spaces, the text-rendering looked the same, even when magnified to 400%. Of course I used color management with a proper monitor profile, at 32-bit floating point precision.

Is it possible that your color management settings are awry?

Is it possible that the babl conversions between linear and perceptually uniform RGB are somehow messing up compositing text-layers over color layers? I used a modified version of babl/GEGL/GIMP in which the babl conversion between linear and perceptually uniform RGB are disabled.

If you are saying that 8-bit images only work with the existing babl code if the images are also sRGB images, then perhaps a babl bug report is in order. Out there in the real world, some people do edit 8-bit AdobeRGB1998 images, even some people who are currently using 8-bit GIMP.

If you are saying that 8-bit "premultiplied alpha" RGB data only works with sRGB images, again that would also seem to be a reason for filing a bug report against the babl code. Or at least it's a reason to warn people in the UI that 8-bit RGB data only works properly for sRGB images.

At all points we know the CIE Lab or XYZ coordinates of all involved pixels

You don't "know" the XYZ coordinates until you actually convert from fooRGB to XYZ. Likewise with CIELAB. So it's not clear what the above sentence really means.

– and we aim to do as few conversions as possible

As few conversions as possible sounds like an excellent maxim for writing image editing software.

Whether you want to go through unbounded sRGB to get to XYZ, CIELAB, etc, for purposes of editing in a reference color space, is entirely irrelevant to RGB editing operations.

But here's a maxim for *RGB* image editing:

For RGB editing operations, don't ever, ever, ever convert color-managed fooRGB to unbounded sRGB.

(never
converting the actual data to either bablRGB or XYZ,

Does "bablRGB" mean fooRGB data that's been converted to unbounded sRGB?

even temporarily
- unless requested.)

Who does the requesting? The artist? Nope, the developers who write the code decide which color space the image data gets converted to. This brings us back to the main quesion:

For which specific RGB editing operations do you plan to convert the image from fooRGB to unbounded sRGB before performing the operation(s)?

With respect, Elle Stone

Jon Nordby
2014-10-15 17:27:28 UTC (over 9 years ago)

babl roadmap

On Oct 15, 2014 4:19 PM, "Elle Stone" wrote:

On 10/15/2014 08:30 AM, Øyvind Kolås wrote:

On Wed, Oct 15, 2014 at 2:11 PM, Elle Stone wrote:

Hi, I fear you two are talking past eachother.

I will ask again:

For which specific RGB editing operations do you plan to convert the

image from fooRGB to unbounded sRGB before performing the operation?

Either the answer is "None. For color-managed fooRGB images, all RGB

operations will be done on data encoded using fooRGB primaries."

The answer is (to best of my understanding): Typically none. When chosing to work in myfavoriteRGB for one "scene" (can be a GIMP document), all operations which specify that they work in any RGB color space, using babl_format("scene:RGBA float") will operate on myfavoriteRGB data. So if there is myfavoriteRGB image as input, and that also is the desired output, there will be zero data conversions.

Supporting any RGB spaces should be the case for the vast majority of operations dealing with RGB data, including multiply/invert and similar. With respect to the roadmap, these operations are *currently wrongly tagged* to only work in unbounded sRGB. This is only because we don't have the new architecture implemented yet!

I say 'typically' because if some operation *does* specify babl_format("RGBA float") to indicate that it just works with unbounded sRGB, a conversion will happen. This should of course *only be used in some cases*, when it actually just works with the specific format. I can't immediably think of any usecase for this, but there probably are some.

I hope this addresses some of your concerns, Regards Jon

Simon Budig
2014-10-15 17:46:19 UTC (over 9 years ago)

babl roadmap

Elle Stone (ellestone@ninedegreesbelow.com) wrote:

On 10/15/2014 08:30 AM, yvind Kols wrote:

On Wed, Oct 15, 2014 at 2:11 PM, Elle Stone

When the user opens a color-managed fooRGB image, for which *specific* editing operations will the image be converted to unbounded sRGB?

If the user is putting a text-layer, which has been rendered using cairo and is in 8bit sRGB premultiplied alpha. The compositing of this with preceding data in the layer stack the babl-format of the output buffer of the over/normal compositing operation, as well as the data fetched from both buffer inputs - would likely be RaGaBaA float - if the two linear inputs differ.

I'm not sure why your text-layer stack example is relevant to my very direct and still unanswered question.

As you very well know we don't *have* the specific list of editing operations you ask for. I don't know why you keep repeating the question. You seem to think that not getting an answer to that question proves a point, but I definitely have no idea what the point is.

What would be the benefit of having such a list?

If the implementor of an operation thinks, that an operation needs to work in unbounded bablRGB then it will request bablRGB input and gegl/babl will do its work to provide that.

An example *could* be an operation that does change the "warmth" of an image by simulating lighting by a different illuminant. The operation could request bablRGB input data, convert that to XYZ internally, do the shift, convert back to bablRGB and provide that as output.

But then the author might be better off with requesting the data in XYZ directly, saving him from the work of doing the bablRGB to XYZ conversion: Gegl/Babl does that for him.

Both ways are fine, Gegl/Babl can do this today. It is up to the author to choose and it will be *completely* transparent to the user of the operation.

This is completely independent from how the image pixels are stored in memory, even when they are stored with a different set of RGB primaries.

Gegl/babl in that case will know how to transform the stored pixels into bablRGB the operation requests, and they'll know what to do with the output.

The text example from pippin is supposed to illustrate that Gegl in real world situations has to deal with external sources which are beyond the control of Gimp. And Gegl/Babl provide the facilities to deal with that.

At all points we know the CIE Lab or XYZ coordinates of all involved pixels

You don't "know" the XYZ coordinates until you actually convert from fooRGB to XYZ. Likewise with CIELAB. So it's not clear what the above sentence really means.

If you know the pixel values of a pixel and know how to convert fooRGB to XYZ there is absolutely no need to do the actual conversion. You can still claim that you know the XYZ as well as CIELAB coordinates. You just don't bother to do the conversion until you really need it.

If you know that x is 5 and you know how to calculate the square of a given value you don't need to do the actual calculation. Yet you still "know" in the sense that the specific value is available to you as soon as you need it.

But here's a maxim for *RGB* image editing:

For RGB editing operations, don't ever, ever, ever convert color-managed fooRGB to unbounded sRGB.

I assume that by "RGB editing operations" you're referring to the "math-centric" ones which bluntly apply a mathematical formula to the pixel data, not caring if the operation makes sense from a colorimetric/physics based viewpoint. (Examples would be "multiply" or even "levels" on the RGB channels).

We now have operations who utterly need to know the colorimetric values of a pixel, because they are based on color theory. Shifting the color temperature of an image might be a good example.

We have to be able to mix these operations, because Future Gimp (TM) will head towards non-destructive editing, where the user uses the UI to construct a graph of operations to combine all the image sources to get to the desired result. We don't intend to stick to the "have-an-image, do-an-operation, have-a-new-image, repeat" paradigm.

So we need infrastructure that can mix both, the colorimetric and the math-centric approach. Your proposal of never-ever-converting will make real colorimetric operations a pain, since the color-temperature operation has to accept the fooRGB data, convert it to XYZ, do its operation and convert back to fooRGB, because fooRGB is ultimately what is needed for a potential next math-centric operation.

With the infrastructure proposed by pippin the "math-centric" operations will ask for fooRGB data as input and provide fooRGB data as output. That means that chaining them together will neatly avoid colorspace conversions.

If the user then decides to put a color-temperature change in the mix (lets assume it requests bablRGB as input and provides bablRGB as output, since the author decided against XYZ for some reason) Gegl/Babl will put a fooRGB->bablRGB conversion into the chain. And after the operation there will be a bablRGB->fooRGB conversion to provide the subsequent levels-operation with the desired input. Let this be the only operation in the chain that works in a colorspace other than fooRGB.

Now lets assume the color temperature is configured to shift from 5000K to 5000K, i.e. it is basically a no-op.

Obviously we then burn lots of CPU cycles for an essentially useless op to do a useless color space conversion to bablRGB and back.

However: This has absolutely *no* negative impact on the rest of the chain which operates in fooRGB (ignoring rounding errors, which are probably negligible for the floats we're likely to use in the chain).

The result will be indiscernible from the result we get by removing the unnecessary op. Claiming that this facility would in any sense break the workflow for color managed images is just incorrect.

And note that the choice of color primaries for our "bablRGB" is irrelevant for this argument. They might be the same as for sRGB, but as long as they work as a basis for the colorspace any combination will work, as long as they are known.

Bye, Simon

simon@budig.de              http://simon.budig.de/
Michael Henning
2014-10-15 17:58:33 UTC (over 9 years ago)

babl roadmap

Yes, the majority of operations will operate in myfavoriteRGB space, but you seem to be operating under the premise that absolutely *no* filters can possibly exist that require a specific color space to function properly. This isn't the case.

Take, for example, the color blindness simulation in gimp. This filter tries to simulate color blindness so that artists can create images that look good to people who are color blind. An operation like this should not change based on which working space you choose to edit in; it must always try to be as faithful to colorblindness as possible. For an operation like this, being able to specify the working space on the developer's side is a must. Otherwise, it can't work properly.

While operations like that might not be too common, it should still be physically possible to create them. Before you say "okay, so a proper icc color managed editor will convert between icc profiles, what's the big deal?", realize this: babl is exactly the mechanism that we are using to make that happen. These "background conversions" that you seem to hate so passionately are exactly the same conversions that you already admitted were necessary when copying and pasting between images. Just because conversions shouldn't be common does not mean they should be impossible, or removed altogether.

-- Mike Henning

On Wed, Oct 15, 2014 at 1:27 PM, Jon Nordby wrote:

On Oct 15, 2014 4:19 PM, "Elle Stone" wrote:

On 10/15/2014 08:30 AM, Øyvind Kolås wrote:

On Wed, Oct 15, 2014 at 2:11 PM, Elle Stone wrote:

Hi, I fear you two are talking past eachother.

I will ask again:

For which specific RGB editing operations do you plan to convert the image from fooRGB to unbounded sRGB before performing the operation?

Either the answer is "None. For color-managed fooRGB images, all RGB operations will be done on data encoded using fooRGB primaries."

The answer is (to best of my understanding): Typically none. When chosing to work in myfavoriteRGB for one "scene" (can be a GIMP document), all operations which specify that they work in any RGB color space, using babl_format("scene:RGBA float") will operate on myfavoriteRGB data. So if there is myfavoriteRGB image as input, and that also is the desired output, there will be zero data conversions.

Supporting any RGB spaces should be the case for the vast majority of operations dealing with RGB data, including multiply/invert and similar. With respect to the roadmap, these operations are *currently wrongly tagged* to only work in unbounded sRGB. This is only because we don't have the new architecture implemented yet!

I say 'typically' because if some operation *does* specify babl_format("RGBA float") to indicate that it just works with unbounded sRGB, a conversion will happen. This should of course *only be used in some cases*, when it actually just works with the specific format. I can't immediably think of any usecase for this, but there probably are some.

I hope this addresses some of your concerns, Regards Jon

_______________________________________________ gegl-developer-list mailing list
List address: gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list

Elle Stone
2014-10-15 19:37:01 UTC (over 9 years ago)

babl roadmap

On 10/15/2014 01:58 PM, Michael Henning wrote:

Yes, the majority of operations will operate in myfavoriteRGB space, but you seem to be operating under the premise that absolutely *no* filters can possibly exist that require a specific color space to function properly. This isn't the case.

Actually, I did go through the code base as thoroughly as possible, and I did identify various editing operations that depend on the data being in specific color spaces (not always D50-adapted sRGB). See http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html

Take, for example, the color blindness simulation in gimp. This filter tries to simulate color blindness so that artists can create images that look good to people who are color blind. An operation like this should not change based on which working space you choose to edit in; it must always try to be as faithful to colorblindness as possible. For an operation like this, being able to specify the working space on the developer's side is a must. Otherwise, it can't work properly.

This is one of the operations that I identified. I also noted that ALL such operations should be clearly identified as such in the UI.

While operations like that might not be too common, it should still be physically possible to create them. Before you say "okay, so a proper icc color managed editor will convert between icc profiles, what's the big deal?", realize this: babl is exactly the mechanism that we are using to make that happen.
These "background conversions" that you seem to hate so passionately

The background conversions that I was objecting to two years ago convert between perceptually uniform and linear gamma RGB data, using the sRGB TRC as a stand-in for true perceptual uniformity. Those are the babl/babl/base/util.h TRC flips.

I do recognize (now, but not two years ago) the point of the TRC flips. The point is to be able to flip instantly between linear gamma and perceptually uniform RGB. See
http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html#best-solution

In my working copies of babl/GEGL/GIMP I have the babl TRC flips disabled because the ways in which the user can choose perceptual vs linear encoding are not transparent and also subject to change. But I'm looking forward to having the UI make it easy for the user to be able to switch at will. Assuming the devs will allow the user the freedom to make such choices.

are exactly the same conversions that you already admitted were necessary when copying and pasting between images. Just because conversions shouldn't be common does not mean they should be impossible, or removed altogether.

I've already said elsewhere in this thread that how you get from RGB to XYZ/LAB/etc is really irrelevant as long as the end result is correct. The same thing applies to conversions from one set of RGB primaries to another set of RGB primaries.

Also, given a bug in current LCMS conversions between RGB matrix profiles, I would rather babl did the conversions. See http://sourceforge.net/p/lcms/mailman/message/32834352/

But even when that particular LCMS bug is fixed, there doesn't seem to be any advantage to calling on LCMS to do simple matrix conversions.

The only real drawback to all of the above is I can't see any way a GIMP user can edit their images in an RGB *LUT* color space. From my own point of view, that would never be a concern. But it should be noted that babl/GEGL/GIMP does seem to have this one requirement.

It should be noted that such cases as the colorblind filter and the old device-based code should be treated as explicit exceptions, labelled in the UI.

The guiding principle should be that except in these carefully bracketed and clearly identified cases, the *user* controls the RGB working space, and all RGB editing operations should use the user's chosen primaries.

Kind regards, Elle Stone

Tobias Ellinghaus
2014-10-15 20:19:18 UTC (over 9 years ago)

babl roadmap

Am Mittwoch, 15. Oktober 2014, 15:37:01 schrieb Elle Stone:

[...]

The guiding principle should be that except in these carefully bracketed and clearly identified cases, the *user* controls the RGB working space, and all RGB editing operations should use the user's chosen primaries.

It seems this is the central point. The choice of bablRGB (or linear sRGB or linear Rec709) is merely an implementation detail and only works as the base transformation matrices are calculated on. Think of it as bablXYZ. It's the common ground babl does its color transformations on, just like ICC uses XYZ. This however is not the working space used in the gegl tree and therefore in GIMP. Just as applications using ICC internally don't work on XYZ data.

The reason why babl uses bablRGB instead of XYZ is just so that the common case of using sRGB data that is coming from the outside world (pippin gave the example of text rendered by cairo) can be used directly and doesn't need a conversion step. Code making use of the babl functions is free to keep every imported buffer in its native color space (probably linearized) and the system will make sure that the data is treated the right way when a conversion is required (for example when merging layers -- which format would win is probably a point to be discussed later).

At least that's how I understood the situation.

Kind regards,
Elle Stone

Tobias

Elle Stone
2014-10-16 16:52:54 UTC (over 9 years ago)

babl roadmap

On 10/15/2014 01:46 PM, Simon Budig wrote:

Elle Stone (ellestone@ninedegreesbelow.com) wrote:

On 10/15/2014 08:30 AM, yvind Kols wrote:

On Wed, Oct 15, 2014 at 2:11 PM, Elle Stone

When the user opens a color-managed fooRGB image, for which *specific* editing operations will the image be converted to unbounded sRGB?

As you very well know we don't *have* the specific list of editing operations you ask for. I don't know why you keep repeating the question. You seem to think that not getting an answer to that question proves a point, but I definitely have no idea what the point is.

You make a very fair point. A better way to ask my question would have been "By what criteria will the devs decide whether an RGB operation should use sRGB primaries instead of UserRGB primaries?"

The babl roadmap says gamma slider and multiply compositing will be done using UserRGB. The roadmap's implied criteria for which RGB operations use sRGB primaries seems to be "If it works in unbounded sRGB, use sRGB primaries; otherwise use UserRGB primaries".

If I understand them correctly, Michael Henning and Jon Norby are saying that the criteria is something along the lines of: "For RGB editing operations, use UserRGB primaries *unless* there's a really, really good reason why only sRGB primaries will work."

Is there in fact general agreement among the devs that the criteria for deciding when to use sRGB primaries instead of UserRGB primaries is approximately as follows?

"For RGB editing operations, use UserRGB primaries except in the rare cases for which only sRGB primaries will work."

Kind regards, Elle Stone

Øyvind Kolås
2014-10-16 19:37:58 UTC (over 9 years ago)

babl roadmap

On Thu, Oct 16, 2014 at 6:52 PM, Elle Stone wrote:

On 10/15/2014 01:46 PM, Simon Budig wrote: If I understand them correctly, Michael Henning and Jon Norby are saying that the criteria is something along the lines of: "For RGB editing operations, use UserRGB primaries *unless* there's a really, really good reason why only sRGB primaries will work."

Is there in fact general agreement among the devs that the criteria for deciding when to use sRGB primaries instead of UserRGB primaries is approximately as follows?

Once we have the vocabulary to also describe this aspect of the pixelformats used by operations, the first thing we should do is to annotate all the operations which are broken when done with sRGB primaries, then we will be able to continue refactoring, profiling and optimizing; without breaking existing functionality/rendering. Not only in terms of making more operations request directly userRGB, but also doing things like make some linear operations accept any of userRGB or bablRGB (or other linear RGB); and creating output buffers in the same format – to avoid unnecessary conversions in such cases.

Using a fixed linear RGB format instead of userRGB is what for some operations will provide the consistent results for the same property values / slider positions. Knowing which operations this is important for is easier to determine when we have code providing the vocabulary in babl. The further along on the roadmap, more of the road will have to be laid/determined as we walk it.

Jon Nordby
2014-10-16 22:49:57 UTC (over 9 years ago)

babl roadmap

On 16 October 2014 21:37, Øyvind Kolås wrote:

On Thu, Oct 16, 2014 at 6:52 PM, Elle Stone wrote:

On 10/15/2014 01:46 PM, Simon Budig wrote: If I understand them correctly, Michael Henning and Jon Norby are saying that the criteria is something along the lines of: "For RGB editing operations, use UserRGB primaries *unless* there's a really, really good reason why only sRGB primaries will work."

Is there in fact general agreement among the devs that the criteria for deciding when to use sRGB primaries instead of UserRGB primaries is approximately as follows?

Once we have the vocabulary to also describe this aspect of the pixelformats used by operations, the first thing we should do is to annotate all the operations which are broken when done with sRGB primaries, then we will be able to continue refactoring, profiling and optimizing; without breaking existing functionality/rendering. Not only in terms of making more operations request directly userRGB, but also doing things like make some linear operations accept any of userRGB or bablRGB (or other linear RGB); and creating output buffers in the same format – to avoid unnecessary conversions in such cases.

Using a fixed linear RGB format instead of userRGB is what for some operations will provide the consistent results for the same property values / slider positions. Knowing which operations this is important for is easier to determine when we have code providing the vocabulary in babl. The further along on the roadmap, more of the road will have to be laid/determined as we walk it.

Hi pippin,
you are answering in detail 'how we will get "there"' but Elle (as I see it) is asking more 'do you agree that we want to go "there"'. This leaves me unsure if you are implicitly agreeing, if you disagree and have a different "there" in mind, or if you think it is too early to decide this.

"There" being the goal that *eventually* in GEGL 'For RGB editing operations, use UserRGB primaries *unless* there's a really, really good reason why only sRGB primaries will work.'

Jon Nordby - www.jonnor.com
Øyvind Kolås
2014-10-16 23:23:53 UTC (over 9 years ago)

babl roadmap

On Fri, Oct 17, 2014 at 12:49 AM, Jon Nordby wrote:

you are answering in detail 'how we will get "there"' but Elle (as I see it) is asking more 'do you agree that we want to go "there"'. This leaves me unsure if you are implicitly agreeing, if you disagree and have a different "there" in mind, or if you think it is too early to decide this.

"There" being the goal that *eventually* in GEGL 'For RGB editing operations, use UserRGB primaries *unless* there's a really, really good reason why only sRGB primaries will work.'

All of the above. I'm stating in detail how we will get as far as I can see into the future; which will bring us closer to "there". As well as reasons it probably will not a be binary choice when we have more knowledge of the capabilities and constraints. The level of detail of the roadmap is in places already too high as it both tries to document an intermediate state as well as hint at where we possibly want to go from there - and bits of what it documents will probably already be invalid by the time much of it is in place.

Elle Stone
2014-10-17 10:01:57 UTC (over 9 years ago)

babl roadmap

On 10/16/2014 03:37 PM, Øyvind Kolås wrote:

On Thu, Oct 16, 2014 at 6:52 PM, Elle Stone wrote:

Is there in fact general agreement among the devs that the criteria for deciding when to use sRGB primaries instead of UserRGB primaries is approximately as follows?

the first thing we should do is to annotate all the operations which are broken when done with sRGB primaries

In other words, you will make a list of all operations that "don't work" in unbounded sRGB, and then you will convert from unbounded sRGB to UserRGB for those operations, and then back to unbounded sRGB. Good luck with that.

Using a fixed linear RGB format instead of userRGB is what for some operations will provide the consistent results for the same property values / slider positions.

As a maxim for guiding GIMP development, "consistent results for the same property values / slider positions" reflects a profound failure to understand the nature of RGB image editing and can only lead to bad code.

With respect, Elle Stone

Elle Stone
2014-10-17 10:04:52 UTC (over 9 years ago)

babl roadmap

On 10/14/2014 08:50 AM, Simon Budig wrote:

for conversions between RGB working spaces there is no fundamental distinction between XYZ and unbounded linear gamma sRGB.

There is one fundamental difference between XYZ as the real PCS and "sRGB as PCS" (those are scare quotes; the terminology "sRGB as PCS" is misleading at best):

Worked out step by step:

It takes one matrix multiplication to get from UserRGB to XYZ. The required matrix "A" is contained in the UsrRGB ICC profile colorants.

It takes a second matrix multiplication to get from XYZ to sRGB. The required matrix "C" is the inverse of the matrix contained in the sRGB ICC profile colorants.

A and C are both defined in terms of XYZ.

Once you have matrix A for getting from UserRGB to XYZ and matrix C for getting from XYZ to sRGB, you can concantenate the two multiplications into one matrix multiplication. This is because matrix multiplication is associative:

C*(A*B) = (C*A)*B, where B is the UserRGB RGB values that will be converted to sRGB (linearized RGB data is assumed).

One matrix multiplication or two, you still get to the same place.

But the required "one matrix to multiply" first has to be *calculated* using *two* matrices, both of which are defined in terms of the real PCS, which is XYZ.

Then you have to store the result of C*A in memory for future use.

Pippin wants to go through "sRGB as PCS" to get to XYZ.

In a sane color-managed editing application, it takes one matrix multiplication to get from UserRGB to XYZ, using matrix A.

In Pippin's "sRGB as PCS", first you convert from UserRGB to sRGB using the matrix that's the product of C*A, that you've previously stored somewhere in memory.

Then you convert from sRGB to XYZ using the inverse of C. Two conversions. Which of course can in turn be concantenated into one multiplication and also stored in memory for future use.

Kind regards, Elle Stone

http://ninedegreesbelow.com
Color management and free/libre photography
Øyvind Kolås
2014-10-17 10:08:31 UTC (over 9 years ago)

babl roadmap

On Fri, Oct 17, 2014 at 12:01 PM, Elle Stone wrote:

On 10/16/2014 03:37 PM, Øyvind Kolås wrote:

On Thu, Oct 16, 2014 at 6:52 PM, Elle Stone wrote:

Is there in fact general agreement among the devs that the criteria for deciding when to use sRGB primaries instead of UserRGB primaries is approximately as follows?

the first thing we should do is to annotate all the operations which are broken when done with sRGB primaries

In other words, you will make a list of all operations that "don't work" in unbounded sRGB, and then you will convert from unbounded sRGB to UserRGB for those operations, and then back to unbounded sRGB. Good luck with that.

Using a fixed linear RGB format instead of userRGB is what for some operations will provide the consistent results for the same property values / slider positions.

As a maxim for guiding GIMP development, "consistent results for the same property values / slider positions" reflects a profound failure to understand the nature of RGB image editing and can only lead to bad code.

No I am explaining how we will start out making these changes for engineering reasons. How to follow a process that doesn't destabilize and destroy what we already have. While your back-seat driving, asking about detailed choices of side-roads 4 weeks from now on our road-trip is not very productive when we're not even sure we'll be in the country of those roads you want us to take – or if we will have swapped the hummer for a jeep.