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.

/Ø

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.

/Ø

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

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.

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/

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/

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

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/

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.

+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.

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

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

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

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.

/Ø

+ > 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

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

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/

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

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

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.

/Ø

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

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.

/Ø

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.