On Sat, Oct 4, 2014 at 2:46 PM, Elle Stone wrote:

Based on the groundless premise that editing operations should produce the same results when performed on the same colorimetric colors, ..

No; but same parameters for same input colors producing same results is considered desirable behavior. Predictable interfaces are nice interfaces.

... the BABL/GEGL/GIMP architecture specifies that:

1. sRGB should be the universal RGB working space.

No.. but GEGL stores the pixel-format/color-space of a pixels values along with the pixel as it is passed around (along with the whole GeglBuffer actually). Internally GEGL doesn't use ICC for this but BablFormats which represents a subset of possible ICC formats. The "profile connection space" used by babl is linear RGB with sRGB primaries, since this permits very low overhead for doing operations in this color space; a color space which also is suitable for these operations (most layer compositing modes and blurring). The intention is to keep using babl for internal buffer management and integrate well with an external color management system for interacting with the more complex things ICC profiles express.

2. Developers should decide whether an operation is done using linear RGB or RGB encoded using the "almost perceptually uniform" sRGB TRC.

Almost, developers decide which pixelformat is appropriate for their operation, with a choice of linear RGB, sRGB, CIE Lab, some gray scale formats as well as formats used with digital video with different data types; currently the set of babl formats. The problems you've pointed out with for instance multiply have led to a consensus that we will also need a target-space/working-space choice, perhaps two; one linear and one more perceptual.

The logic involved in configuring the pixel format inputs/outputs of each operation could possibly be made more configurable (in GEGL, not necessarily work to be done by the implementor of the op), thus also enabling mostly conversion free processing modes of operation like what you seem to want when you reduce babl to only deal with precision conversion.

/pippin

On Sun, Oct 5, 2014 at 5:16 PM, Elle Stone wrote:

On 10/04/2014 11:59 AM, Øyvind Kolås wrote:

On Sat, Oct 4, 2014 at 2:46 PM, Elle Stone wrote:

Based on the groundless premise that editing operations should

produce the

same results when performed on the same colorimetric colors, ..

No;

I'm not sure what you are saying "No" to. Here are excerpts from previous posts that you've made talking about the matter: http://article.gmane.org/gmane.comp.video.gimp.devel/19916

I am saying no to it being groundless premise, It is a desirable interaction goal.

It is the same desire that makes sure that things like image resampling and blurring should always happen with _associcated_alpha_ and linear TRC. Instead of letting the user configure a working space where scaling or blurring behaves in ways not resembling physics.

The architectural implementation of that desire is tagging of all buffers explicitly with their color space, associated alpha state, data type etc.
Each operation tells GEGL both what type of data it wants to read as well as what type of data it wants to write in the "prepare" stage for the op, which happens before any data is being processed. With what has been proposed as a solution for ops that need to use a target/working RGB space is that the operation would ask for a special symbolic babl format or similar; and GEGL/babl does the rest behind the scenes.

Most current named BablFormats are immutable - in the same ways ICC profiles are treated as immutable. Changing the meaning of "R'G'B'A u8" or "Y'CbCr u8" and similar will break color management for operations providing integration with various image loaders/video codecs/webcam/GUI that already exist.

My stance is that the sliders on an operations should be predictable and always do the same thing for the colorimetrically absolute same color

(relative colorimetric likely makes more sense; or perhaps just colorimetric - though thats a detail).

http://markmail.org/message/n6ttql3ajtjbe767

GEGLs image processing is intended to all operate in device independent color spaces, no matter which camera you took a picture with gaussian blurs, color adjustments etc, should behave the same.

No; but same parameters for same input colors producing same results is considered desirable behavior. Predictable interfaces are nice interfaces.

In a properly color managed image editor, the way for a user to get predictable editing results is to set up a consistent workflow based on the RGB working spaces that the user finds appropriate for the tasks at hand.

I don't think a medium high-end user of GIMP should _need_ to be concerned about working spaces; we should strive to make a system that behaves well by default.

Until GIMP is properly color managed, the only users who might find GIMP editing results predictable are users who already only edit their images in the sRGB color space.

GEGL strives to bring linear light editing all the places it makes sense; this will hopefully be a better experience than 8bpc sRGB.

"properly color managed" is not one single thing, sure GIMP/GEGL is not there yet, but for a GIMP 2.10 release it is good enough. (2.10s stated goal is being to be able to do what 2.8 does; but with GEGL inside - the higher bitdepths and such are bonus.). One could also claim that a system that converts everything to a single working space and passes pixels untagged through is "weaker" color managed than the plan that has been outlined for GEGL.

You've already been invited, and I invite you again to spend some time with the rest of the GIMP team and others with interest in color, photography and graphics in Toronto, end of april next year for the next Libre Graphics Meeting.

/Ø

On Mon, Oct 6, 2014 at 6:57 PM, Elle Stone wrote:

On 10/05/2014 12:49 PM, Øyvind Kolås wrote: You've conceded that your architecture is broken to the point where you must hack in fixes for multiply. That's the first of many such hacks to come:

This is not the first such aspect of how pixel representation affects computation that operation developers must take into consideration for their operation (in which BablFormats they request). It is the same type of choice already existing with regard to linear/perceptual as well as pre-multiplied alpha or not, and should be dealt with in a similar way.

I am going to try to describe the architecture of babl without mentioning color.. instead of doing color computations we will pretend to be doing temperature computations. Exactly how GEGL uses babl is not relevant for the discussion.

Unfortunately enough - humans have many temperature scales, and they use different temperature scales for different purposes. To facilitate cooperation between scientists, engineers and others we have developed a convention of tagging numbers we use to refer to temperature with a unit qualifier, like thus: 37.7°C 100°F 310.9°K. That way, given a set of conversions formulas, it is possible to operate in the preferred unit. Some chemists need to do computations based on temperature relative to the _local_ boiling point of water. To facilitate this one can introduce a convention of local temperature; which could be 0.0 T at 0.0 C and 100.0 T when water boils at current altitude, that would might make these computations easier, this unit is the same as C some places on earth and different elsewhere.

Being unchangeable units - like - C, K and F is the purpose for BablFormats existing, and the unit T is the proposed extension of our vocabulary for these recipies/chemistry formulas/whatisit that works differently at different heights.

I understand you to propose using T everywhere; (or a set of new Ts; because in our case the differences between C and F are more important than in the real world, and mean alpha/linearity/precision). Or that interfaces at the edges of our system that are using C and F and working well with it should be discarded or reimplemented - because C and F will no longer mean what they meant when these systems were established.

/pippin

Hi,

although you and Elle are discussing this topic, I'd like to give my 2 cents

Am 06.10.2014 um 21:54 schrieb Øyvind Kolås : To facilitate
cooperation between scientists, engineers and others we have developed a convention of tagging numbers we use to refer to temperature with a unit qualifier, like thus: 37.7°C 100°F 310.9°K. That way, given a set of conversions formulas, it is possible to operate in the preferred unit.

Of course, you can do operations in your preferred unit, but that does not mean, that your computation will give identical results after you convert your result of your preferred unit back to the original unit. And that's what you implicitly say: operating in a "converted unit" and converting back will give identical results, as if operating in any original unit only. Or in GEGL/BABL words: operating in unbounded sRGB and converting back to the original space will give identical results as operating in the original space only.

You've given a very good example for that:

If x C = y F
and
x C = z T, where T is your "TCS" , your "temperature connection space" is true,

you know that

2*x C != 2*y F and
x C + 10 C != y F + 10 C
and
x C + 10 C != y F + 10 F

is true too.

and so although 2*x C = 2*z T
there is
2*z T != 2*y F
and
z T + 10 T != y F + 10 F

So doing an operation in T, either multiply or adding, and converting back, won't be the same as computing in the original unit in your example. Same applies to color space computations and various operations.

BTW, I've noticed, that although Elle always gives equations or real world examples and images to prove her statements, you don't. So, I'd like to ask you for such a mathematical equation or real world example for your statements.

Finally and sorry to say so, AFAICS, Elle is right.

Kind regards Simone Karin

Hi,

On 4.10.2014 at 5:59 PM yvind Kols wrote:

Almost, developers decide which pixelformat is appropriate for their operation, with a choice of linear RGB, sRGB, CIE Lab, some gray scale formats as well as formats used with digital video with different data types; currently the set of babl formats.

perhaps I missed or forgot something: what happens if a GEGL operation is called with a wrong pixel format - will the operation refuse to work or the data be converted to an appropriate format?

Kind regards

Sven

On Tue, Oct 7, 2014 at 8:13 PM, scl wrote:

On 4.10.2014 at 5:59 PM Øyvind Kolås wrote:

Almost, developers decide which pixelformat is appropriate for their operation, with a choice of linear RGB, sRGB, CIE Lab, some gray scale formats as well as formats used with digital video with different data types; currently the set of babl formats.

perhaps I missed or forgot something: what happens if a GEGL operation is called with a wrong pixel format - will the operation refuse to work or the data be converted to an appropriate format?

tl;dr: converted to an appropriate format.

The operations provide a hint to GEGL about the format it is going to do read-requests with in :prepare() . GEGL does not need to abide by this request though; and will most of the time just pass the GeglBuffer on. Then in process() when the operation is actually reading data (when a copy from the tiled data structure in the buffer is made linear (or a direct peek at the data in the cases where formats; tiles and more align perfectly)) babl_process() ends up being called behind the scenes with the buffers format as the source format argument and the operations requested format for the pixels as the target format argument. Since all buffers have a babl_format, the data will be converted, if the format is an anonymous n-component format, the components will be type converted blindly.

Since the preceding operation specifies which format it is going to want a GeglBuffer for writing data into. An operation can request already in the prepare stage what formats it's sources will be providing data in, this is already used in some places and can be used for instance for adding 8bit and 16bit fast paths. This mechanism can also be used to treat multiple formats the same (passing them on with their original format.). That way some ops could be made into no-conversion ops by treating different formats that both are linear like for instance babl_format("RGBA float") and an imagined babl_format("target:RGBA float") to both be treated the same. The same way that an op just doing multiplication in the temperature analogy can treat T and C the same in its computation, because they are both linear - and they have the same 0.0.

/Ø

On 7 October 2014 20:13, scl wrote:

Hi,

On 4.10.2014 at 5:59 PM Øyvind Kolås wrote:

Almost, developers decide which pixelformat is appropriate for their

operation, with a choice of linear RGB, sRGB, CIE Lab, some gray scale formats as well as formats used with digital video with different data types; currently the set of babl formats.

perhaps I missed or forgot something: what happens if a GEGL operation is called with a wrong pixel format - will the operation refuse to work or the data be converted to an appropriate format?

The data will be transparently converted (using Babl) so, apart from performance, there is no "wrong" pixel format when passing buffers to GEGL ops.
Assuming that one does to mark the GeglBuffers with misleading BablFormats.

Jon Nordby - www.jonnor.com

On Tue, Oct 7, 2014 at 8:10 PM, Elle Stone wrote:

I'm posting to the original thread. Pippin had started a new thread: https://mail.gnome.org/archives/gimp-developer-list/2014-

gmail started a new thread when I tired to change the alarmist subject.

Brasseur shows why scaling needs to be done on linearized RGB. The defining primaries are irrelevant. Nothing in Brasseur's demonstrations provide any justification for a forced conversion to "sRGB as PCS".

They provide a justification for keeping track of the pixel format of the buffers, or enforcing that only linear spaces are permitted processing spaces. There in practice with regard to data loss, no forced conversion to sRGB. Any more than any use of ICC profiles would be a forced conversion to CIE XYZ.

Babl provides the vocabulary and set of _defined_ units to be able deal with the multitude of temperature units/pixel formats in use by different algorithms and libraries.

I do understand how babl/GEGL works. There is a difference between "understanding" and "agreeing".

To me it seems like you do not like the fact that the neutrally sounding babl_format name "RGBA float" is strictly defined in the architecture of both babl and GEGL, and see this as the thing in the architecture that should be changed to be *the*processing*space*. While I am arguing that this is existing functionality we need; and that reconfigurable primaries should be a separate addition instead of deleting both neccesary functionality and optimizations for common pixel formats.

Any architecture that requires hacks to make basic editing operations work is broken. You can dress it up and make it sound like the hacks are just extending existing functionality. But in this case it's obvious that the reason for the hacks is to fix something that is only broken because of an architecture that intends to use "sRGB as PCS".

Since April I've tried to explain why Pippin's architecture is broken. I've used logic, examples, equations, pictures, long explanations, short explanations, and other people's explanations.

I have not disagreed that the current architecture is broken, but what you call hacks is how GIMP-2.9 avoids gamma errors when blurring and scaling, regardless of wheter you are editing an 8bit image with its layers stored non-linearly or not; as well as other distinctions where different operations have the need to do processing with different pixel representations.

/Ø

On Tue, Oct 7, 2014 at 9:23 PM, Elle Stone wrote:

You could accomplish guiding users as to the right choices regarding linear vs perceptual by creating presets and allowing users the freedom to control their own editing decisions. You don't have to build fences around what people can do with their own RGB color data.

One design maxim is “Make common things easy, rare things possible.”. If there is confidence that a default behavior covers more than 99.999% of uses, and there are intended ways of working around the limitations - I think it might be of the benefit of both the normal user and the deviating expert that likely also does not need to do it in more than a couple of % of cases.

/Ø

On Tue, Oct 7, 2014 at 10:20 PM, Elle Stone wrote:

Who decides what's common and what's rare for an artist to want to do? The GIMP devs? Isn't that just a trifle presumptuous?

These kinds of decisions belong with the users, not the devs.

I'm sorry but you've crossed the line from being a user to a dev. Despite that your input has helped form future priorities.

Don't use code to micromanage what users can do their own data based on what devs think is "common" or "correct". Make it easy for the user to choose between linear vs perceptual for ALL ops, and put in good presets.

Nothing in that quote wants to limit what a user can do; it rather act as a guide when designing interfaces (APIs/GUIs). As a metric to evaluate choices that provide the user (application or human) guidance/constraints making it simple to do the right thing. Rare things that should be possible; preferablly not to difficult either - are choosing which component(s) to gaussian-blur in linear RGB, CIE Lab and possibly other color spaces. That is something which is possible to achieve globally for all operations - without adding the code to do so in each operation. Thus on the GEGL level it would probably be harder to directly do it; than for abstractions possible to add for the user of a GUI like GIMP.

/Ø

On 7.10.2014 at 8:43 PM Øyvind Kolås wrote:

On Tue, Oct 7, 2014 at 8:13 PM, scl wrote:

On 4.10.2014 at 5:59 PM Øyvind Kolås wrote:

Almost, developers decide which pixelformat is appropriate for their operation, with a choice of linear RGB, sRGB, CIE Lab, some gray scale formats as well as formats used with digital video with different data types; currently the set of babl formats.

perhaps I missed or forgot something: what happens if a GEGL operation is called with a wrong pixel format - will the operation refuse to work or the data be converted to an appropriate format?

tl;dr: converted to an appropriate format.

I consider this design decision critical for two reasons:

1) Extra conversions every now and then produce overhead -> increase computation time -> decrease performance. One part of GIMP's product vision is [high working speed] and I don't see how extra overhead can speed up things. And I would not claim GIMP and GEGL to be tigers, especially when it comes to large images. For example adjusting brightness and contrast with preview of a 5184x3456 px photo happens immediately in PS CS5 (from 2010). GIMP 2.8.14 takes 7 seconds and the GEGL tool 'brightness-contrast' takes 16 seconds for the same image on the same machine.

2) Extra computation steps can introduce computation and rounding errors and thus cause wrong results.

These effects might be very low for each single operation, but will sum up when many operations are combined (which naturally happens when editing an image).

I also think that it should be the user's decision whether s/he wants to apply an operation to a coloured image, a grayscale image or a mask. Leaving this decision solely to the developer (who's not necessarily an artist) doesn't satisfy the claim to be a high-end image manipulation program.

Therefore I think it's better to let all operations work on the same appropriate colour space (big enough and computable precisely and efficiently) and do conversions only on the interfaces to the outside world: importing and exporting images, displaying, working with ICC profiles etc. IIRC there was a hint on that in one of the former posts to this topic - what where the reasons to not to do so?

On 5.10.2014 at 6:49 PM Øyvind Kolås wrote:

You've already been invited, and I invite you again to spend some time with the rest of the GIMP team and others with interest in color, photography and graphics in Toronto, end of april next year for the next Libre Graphics Meeting.

+1. What can go wrong? Sometimes meeting the people and talk things over at a coffee or beer is better than throwing arguments back and forth. It's also a great chance to meet creatives and color experts from other libre-graphics-projects and hear their opinions.

Kind regards

Sven

[high working speed]: http://gui.gimp.org/index.php/Vision_briefing#value_.2B_traits

On Wed, Oct 8, 2014 at 4:25 PM, scl wrote:

I consider this design decision critical for two reasons:

1) Extra conversions every now and then produce overhead -> increase computation time -> decrease performance. One part of GIMP's product vision is [high working speed] and I don't see how extra overhead can speed up things. And I would not claim GIMP and GEGL to be tigers, especially when it comes to large images.

Babls conversions are often transparent since they occur where data is copied anyways and memory access is more expensive - the ones doing unpremultiplication of alpha being among the exceptions (as well as when we end up hitting reference paths where we are starting to use new and not even attempted optimized combinations of formats.)

For example adjusting brightness and contrast with preview of a 5184x3456 px photo happens immediately in PS CS5 (from 2010). GIMP 2.8.14 takes 7 seconds and the GEGL tool 'brightness-contrast' takes 16 seconds for the same image on the same machine.

Performance is a concern, but it is different parts of the architecture that needs improvement for that type speed up...

With a GEGL GUI that is not GIMP I've experimented with the new mip-map rendering capabilities recently added to GEGL and previewing of on canvas brightness contrast or gaussian blur/unsharp mask on a 10000x5000 image is instant (it processes somewhere between the number of pixels on screen and 4x that, not more). Allowing you to both adjust the op, pan and zoom at will.

2) Extra computation steps can introduce computation and rounding errors and thus cause wrong results.

These effects might be very low for each single operation, but will sum up when many operations are combined (which naturally happens when editing an image).

Accumulated errors would be a huge concern in 8bit compared to in single precision floating point.

I also think that it should be the user's decision whether s/he wants to apply an operation to a coloured image, a grayscale image or a mask. Leaving this decision solely to the developer (who's not necessarily an artist) doesn't satisfy the claim to be a high-end image manipulation program.

That decision is not set in stone because of the format asked for by the GEGL operation, it is the task of GIMP on top of GEGLs abstractions to provide the means to do so.

Therefore I think it's better to let all operations work on the same appropriate colour space (big enough and computable precisely and efficiently) and do conversions only on the interfaces to the outside world: importing and exporting images, displaying, working with ICC profiles etc. IIRC there was a hint on that in one of the former posts to this topic - what where the reasons to not to do so?

The we have to juggle a large set of different types of pixel formats already? The initial thinking was that linear working in RGB and HDR was sufficient, that is what the current babl is sufficient for, one uses ICC based conversions to get into the internal formats which are supposed to have efficient management, programming naming and conversions. And uses an external CMS for interacting with the outside. As Elle has repeatedly pointed out, that is not sufficient; and the scope of what is considered natively juggled pixel formats must be extended.

/pippin

On Wed, Oct 8, 2014 at 9:49 PM, Elle Stone wrote:

On Wed, Oct 8, 2014 at 4:25 PM, scl wrote: The we have to juggle a large set of different types of pixel formats already? The initial thinking was that linear working in RGB and HDR was sufficient, that is what the current babl is sufficient for, one uses ICC based conversions to get into the internal formats which are supposed to have efficient management, programming naming and conversions. And uses an external CMS for interacting with the outside. As Elle has repeatedly pointed out, that is not sufficient; and the scope of what is considered natively juggled pixel formats must be extended.

The babl/GEGL/GIMP code base has a relatively short list of places where hard-coded sRGB parameters are used. I've already identified most such code. Most of it uses sRGB Y values.

Each location that says babl_format("RGBA foo") or babl_format ("R'G'B'A foo") or babl_format ("RaGaB..) etc. is a location that requests a specific format. It is not the places in the code that implements the sRGB primaries which is in question.

To generalize such code to work with all RGB working spaces, replace hard-coded sRGB Y values with Y values retrieved by LCMS from the user's chosen RGB working space colorant XYZ values. The Y values can be retrieved upon opening an image and again upon switching images for users who have several images open at once.

What you are describing is exactly what I outlined API for elsewhere. You would..
babl_set_named_rgb_chromaticities (babl, "hack", colorants.. and you would get what you want by having replacing all occurences of "RGBA float" and "R'G'B'A float" with "hack:RGBA float" and "hack:R'G'B'A float", and the same for u8 and u16. But the "R'G'B'A u8" and u16 and similar better be left alone because they have been written with the assumption that their data is sRGB. Globally switching it upon switching images does not work for copy and paste between images and other forms of work where different spaces might be at play.

The babl conversion to XYZ uses the sRGB D65 color space xy values and the D65 white point to convert to XYZ. This results in wrong results even for sRGB images in a D50-adapted ICC profile color-managed workflow. The right thing to do is retrieve the user's chosen profile's colorant XYZ values and ferry that to babl. This takes the place of the hard coded (and wrong) D65 sRGB xy values. The equations for converting from XYZ to LAB are well known.

Babl has no XYZ format and thus in a sense no conversion to XYZ. The CIE Lab implementation which came from GIMP does however contains an internal conversion to XYZ; you are saying the CIE Lab code is broken.

I don't understand why replacing the hard-coded sRGB parameters is meeting such massive resistance. It's the right thing to do. I don't see how it can require more overhead than retrieving the target color space information anyway and using it to constantly convert back and forth between "sRGB as PCS" and the target color space for the many operations that won't work correctly in "sRGB as PCS"

Since one approach permits internal color management, and the other permits managing sRGB TRC perceptual vs not. Would require conversions involving the external CMS for all things doing cross window/document copy, paste, cloning and more. Keeping babl as an actual CMS and not one with only one reconfigurable RGB model permits the above, as well as keeping the contract with existing GEGL operations, as well as applications using GEGL to what the pixel format identifiers mean; we're not designing a system from scratch, but we try to change what we have; without breaking much; to be able to do much more. Ripping out the PCS of the internal color management system; would break things.

Even though I know that many find the idea of writing here intimidating; I am hope some that are agreeing with the direction GEGL has been trying to go in on the projects in our other communication channels also chime in.

/Ø

Hi Pippin,

I hope you don't see my lines as picking on your work, but as the constructive criticism as it is meant. GIMP has performance issues, especially with large images and modern camera sensors are just delivering them.

On 8.10.2014 at 4:47 PM Øyvind Kolås wrote:

On Wed, Oct 8, 2014 at 4:25 PM, scl wrote:

1) Extra conversions every now and then produce overhead -> increase computation time -> decrease performance. One part of GIMP's product vision is [high working speed] and I don't see how extra overhead can speed up things. And I would not claim GIMP and GEGL to be tigers, especially when it comes to large images.

Babls conversions are often transparent since they occur where data is copied anyways and memory access is more expensive - the ones doing unpremultiplication of alpha being among the exceptions (as well as when we end up hitting reference paths where we are starting to use new and not even attempted optimized combinations of formats.)

What I don't see is not there? - Let's not put the head in the sand. The point is not whether they are transparent or not, but whether they are necessarily done or not.
Also, how does memory access instead of converting come in here?

For example adjusting brightness and contrast with preview of a 5184x3456 px photo happens immediately in PS CS5 (from 2010). GIMP 2.8.14 takes 7 seconds and the GEGL tool 'brightness-contrast' takes 16 seconds for the same image on the same machine.

Performance is a concern, but it is different parts of the architecture that needs improvement for that type speed up...

With a GEGL GUI that is not GIMP I've experimented with the new mip-map rendering capabilities recently added to GEGL and previewing of on canvas brightness contrast or gaussian blur/unsharp mask on a 10000x5000 image is instant (it processes somewhere between the number of pixels on screen and 4x that, not more). Allowing you to both adjust the op, pan and zoom at will.

This is a display trick to give the user immediate control (and a good idea for GIMP, too). However, the whole image has to be processed anyway. Display tricks can hide an underlying problem, but not solve it.

I also think that it should be the user's decision whether s/he wants to apply an operation to a coloured image, a grayscale image or a mask. Leaving this decision solely to the developer (who's not necessarily an artist) doesn't satisfy the claim to be a high-end image manipulation program.

That decision is not set in stone because of the format asked for by the GEGL operation, it is the task of GIMP on top of GEGLs abstractions to provide the means to do so.

...which ends up in refusing the op or converting the data and the circle closes here. Or is there something else?

Therefore I think it's better to let all operations work on the same appropriate colour space (big enough and computable precisely and efficiently) and do conversions only on the interfaces to the outside world: importing and exporting images, displaying, working with ICC profiles etc. IIRC there was a hint on that in one of the former posts to this topic - what where the reasons to not to do so?

The we have to juggle a large set of different types of pixel formats already?

I thought of the same (=a common) colour space for all ops, leading to a commonly shared pixel format which makes conversions unnecessary. You and Elle are the right people to find that space and fine tune its implementation and I hope you both are open enough to find a good solution together.

Kind regards

Sven

On Thu, Oct 9, 2014 at 8:00 AM, Elle Stone wrote:

To somewhat simply, ICC RGB working space profiles are characterized by:

1. The profile Red, Green, and Blue colorant XYZ values, aka "primaries".

2. The profile Tone Reproduction Curve, "TRC" for short.

Right now, when a user opens a regular ProPhotoRGB image, the primaries AND the TRC are not what the babl/GEGL/GIMP code expects (the regular ProPhotoRGB TRC is Gamma=1.8). The only operations that *don't* produce wrong results are operations that don't use sRGB primaries AND don't linearize the sRGB TRC.

Yes, the current color management is somewhat unfinished and broken with respect to importing/exporting. Nobody claimed that is was correct. It does not implement the planned design yet.

You can make an ICC profile using any primaries and any TRC. For example, a profile can be made using the ProPhotoRGB primaries and the sRGB TRC. So here is one way to make the current hard-coded sRGB TRC-based transforms between linear and perceptually uniform RGB work:

Upon opening an image, use LCMS to make a profile using the user's chosen primaries and the sRGB TRC, and convert the image to this new profile. Once. Not repeatedly back and forth.

Yes, on import, we should definitely convert the TRCs. We don't do this right now because the code isn't finished.

And of course replace all the code that uses hard-coded sRGB primaries.

The idea is to not completely replace the sRGB code, but just add a new code path that supports RGB spaces with different primaries. See my remarks below.

I have two questions about the linear-to-perceptual "babl TRC flips" code:

1. Is it acceptable to mess with a user's RGB data by keeping the primaries intact and "only" modifying the TRC? A user who expects their data is encoded using the ProPhotoRGB gamma=1.8 TRC will not fail to notice that data encoded using the sRGB TRC gives different results.

The "babl TRC flips" code could be modified to give the user a choice of TRCs for encoding perceptually uniform RGB.

We were planning to include support for a choice between linear RGB w/ user primaries and sRGB-TRC RGB with user primaries, with the idea that both a perceptual and a linear space is enough to support all the required editing operations.

Then, many operations which only make sense with a given TRC would specifically use that TRC. For example, downscaling might do a conversion so it always happens in linear space.

2. Does the repeated linear-to-perceptual-to-linear "babl TRC flips" required by the current architecture impose a loss of precision? How much loss, after how many flips?

Yes, there is a small loss in precision. I think Daniel Sabo did some tests to try and exactly quantify the error a while back, although I forget the results. This certainly is a concern though, and work has been done to minimize the error in conversions.

That being said, the operations themselves don't exactly have infinite precision either; nearly any floating point computation has the potential to throw away some data. The simple act of adding two numbers in floating point can throw away data (I can provide examples, if you're interested). To some degree you just need to live with that fact in any floating point image editor.

What you are describing is exactly what I outlined API for elsewhere. You would..
babl_set_named_rgb_chromaticities (babl, "hack", colorants.. and you would get what you want by having replacing all occurences of "RGBA float" and "R'G'B'A float" with "hack:RGBA float" and "hack:R'G'B'A float", and the same for u8 and u16.

I'm not proposing that you use "sRGB as PCS" and then hack the code to fix the resulting problems. I'm proposing that you eliminate "sRGB as PCS" altogether. It's a broken model for RGB editing.

The VFX people understood with *one* multiply example that there can be no universal RGB working space. The best working space depends on the artistic intent plus the device(s) that produced the colors, and eventually on the device(s) on which the colors will be displayed.

I'm not entirely clear which concept you're trying to refute in that section. sRGB as a PCS, or sRGB as a universal working space? They're two different concepts, and while you said sRGB as a PCS, you arguments seem to be about sRGB as a working space to me.

Øyvind's proposal is no longer to have a universal working space. sRGB would remain in babl as the PCS, but the results of the color conversions would be indistinguishable from if we chose, say XYZ as a PCS.

Ie, babl will support your suggestion (user-chosen primaries with either linear or sRGB TRC) in addition to sRGB, instead of replacing sRGB. Gimp/gegl will then switch to using the working space profile instead of always using sRGB. Having sRGB still around won't make a big difference from the user's standpoint, but it makes the code a little nicer.

Adobe-centric advice implies that color gamut is the only consideration when choosing an RGB working space. Adobe has hard-coded ProPhotoRGB primaries into their raw processing software. It is distressing to see GIMP follow Adobe's lead by writing code on the assumption that the sRGB primaries are suitable for editing all images.

I'll repeat that the sRGB primaries won't be the only supported working space. You talked us out of that idea a long time ago.

But the "R'G'B'A
u8" and u16 and similar better be left alone because they have been written with the assumption that their data is sRGB.

If there is code for 8-bit and 16-bit integer images that uses sRGB *primaries*, that code needs to be rewritten or removed. It makes no sense in the context of a high end, high bit depth image editor.

I think this was a little confusing. Øyvind seems to be talking about the large quality loss that's inherent in converting between different color spaces while using 8 or 16-bit integers. Personally, I think we should have the capability of having integer data in different working spaces, and there's no technical reason why that's impossible.

Globally
switching it upon switching images does not work for copy and paste between images and other forms of work where different spaces might be at play.

Copy-paste/drag-drop do require converting the pixels from the source layer stack's ICC profile to the destination layer stack's ICC profile. That's what properly color-managed image editors do. Krita does this. Surely GIMP can also do this.

Whether babl does the color conversions or lcms does the color conversions will not make a difference; as long as the color conversions are implemented properly, they will produce the same output. So yes, we will do proper conversions on copy/paste. Øyvind was just talking about an implementation detail that needs to be worked out.

The babl conversion to XYZ uses the sRGB D65 color space xy values and the
D65 white point to convert to XYZ. This results in wrong results even for sRGB images in a D50-adapted ICC profile color-managed workflow. The right
thing to do is retrieve the user's chosen profile's colorant XYZ values and
ferry that to babl. This takes the place of the hard coded (and wrong) D65
sRGB xy values. The equations for converting from XYZ to LAB are well known.

Babl has no XYZ format and thus in a sense no conversion to XYZ. The CIE Lab implementation which came from GIMP does however contains an internal conversion to XYZ; you are saying the CIE Lab code is broken.

My apologies, I meant to type "RGB to XYZ to LAB". You can't get directly from RGB to LAB. You have to go through XYZ. You get from RGB to XYZ by using the illuminant-adapted profile colorants.

Okay, that needs fixing, then.

Also, proper "color temperature change" code requires converting to XYZ to do Bradford/CATO2/etc chromatic adaptation. So a function that converts from RGB to XYZ really is necessary. The current temperature change code is hard-coded for sRGB images and although it does produce pleasing results for sRGB images, those results are not colorimetrically correct.

I'm not totally clear on this point. Are you saying that it produces incorrect results for sRGB, or that it produces incorrect results for different color spaces? I'm not too familiar with this part of the code.

Thanks for the input.

From, Michael Henning

On Thu, Oct 9, 2014 at 6:27 PM, Michael Henning wrote:

But the "R'G'B'A
u8" and u16 and similar better be left alone because they have been written with the assumption that their data is sRGB

If there is code for 8-bit and 16-bit integer images that uses sRGB *primaries*, that code needs to be rewritten or removed. It makes no sense in the context of a high end, high bit depth image editor.

I think this was a little confusing. Øyvind seems to be talking about the large quality loss that's inherent in converting between different color spaces while using 8 or 16-bit integers. Personally, I think we should have the capability of having integer data in different working spaces, and there's no technical reason why that's impossible.

I am referring to the places in the code that is explicitly using the 8bpc or 16bpc "R'G'B.." formats. These are likely integration points with other systems/libraries that in their api/format/data exchange contract always should be interpreted as 8bit sRGB; like many file formats both in use and legacy. I added some architecture notes and a small write up of the plans as they relate to babl in the git repo; where I elaborate how we can move forward with managing pixel/formats and color spaces.

/Øyvind

On Thu, Oct 9, 2014 at 7:22 PM, Elle Stone wrote:

My assumption was that "sRGB as PCS" only made sense in the context of using unbounded sRGB as a universal working space.

If "sRGB as PCS" means that unbounded linear gamma sRGB is used to convert from RGB to XYZ to LAB, for example, then I'm not sure when "sRGB as PCS" would be used. For example, for converting to LAB, use the user-chosen primaries (colorants) to convert to XYZ and then to LAB.

See below.

Ie, babl will support your suggestion (user-chosen primaries with either linear or sRGB TRC) in addition to sRGB, instead of replacing sRGB.

Does "in addition to sRGB" mean duplicate code files side by side, one set of files hard-coded for just sRGB images and one using Y and XYZ values retrieved from the user's chosen primaries? For example, the babl code that converts from color to Luminance for painting on a mask would be duplicated, once for sRGB and once generalized?

To some degree, yes.

We don't need to recreate every single transformation. For example, when converting from some arbitrary RGB color space to luminance, we can chain the conversions: first, one conversion from the user-specified RGB space to linear sRGB, and then from linear sRGB to luminance. If that's too slow, we also have the option of defining "fast paths" that convert directly between two color spaces, but the core of babl always converts to linear sRGB as an intermediate. This is what we mean when we say "sRGB as PCS": all of the color formats are defined in terms of linear sRGB, so if a given transformation hasn't been coded specifically, we can use linear sRGB as an intermediate.

Also, some portions of sRGB will probably share code with the generic RGB code. But, the important point is that we want sRGB to still exist within babl as a usable, built-in format.

Adobe-centric advice implies that color gamut is the only consideration when
choosing an RGB working space. Adobe has hard-coded ProPhotoRGB primaries into their raw processing software. It is distressing to see GIMP follow Adobe's lead by writing code on the assumption that the sRGB primaries are
suitable for editing all images.

I'll repeat that the sRGB primaries won't be the only supported working space. You talked us out of that idea a long time ago.

Oh. I didn't realize that.

Maybe we weren't too clear. :P

The temperature change code produces very pleasing results for sRGB images, much nicer than another editor that I tried. Based on eyedroppering and comparing to spreadsheet calculations, the colors aren't colorimetrically correct and maybe they never were intended to be. On the other hand, I only checked Bradford adaptation and I'm not 110% certain I handled all the matrix math correctly.

The current code uses hard-coded coefficients based on sRGB primaries and produces obviously wrong results for non-sRGB images. Bradford/CAT02 etc chromatic adaptation code would seem to be a logical generalized replacement.

This article demonstrates using CAT02 to do color temperature corrections: http://nbviewer.ipython.org/gist/kelsolaar/7098c6709c59b9afb018 The article uses the D65 sRGB color space, not the D50-adapted sRGB ICC profile color space, but it illustrates the math nicely.

Okay, we should probably look at that then.

From, Mike Henning

On Fri, Oct 10, 2014 at 6:36 PM, Elle Stone wrote:

On 10/09/2014 07:52 PM, Michael Henning wrote:

On Thu, Oct 9, 2014 at 7:22 PM, Elle Stone

So where in the conversion to XYZ and then to LAB (or any other reference color space) will "sRGB as PCS" fit in?

Of course you could convert from User_RGB to XYZ, from XZY to "sRGB as PCS", from "sRGB as PCS" back to XYZ, and then, finally, to LAB. But I don't see the point of doing such an odd sequence of conversions.

This conversion would be User_RGB -> "sRGB PCS" -> LAB. While Linear User_RGB to Linear User_RGB2, might end up being just be Linear User_RGB -> Linear User_RGB2.

The choice of XYZ or linear sRGB or any other linear RGB as a PCS should not have an impact on either the results you get or the number of conversions happening - when converting between RGB spaces.

Any linear RGB space is a matrix multiplication away from XYZ, this includes the PCS of babl. Two such matrix multiplication steps can be combined into a single step by multiplying the matrices corresponding to the steps. Thus the number of operations to do per pixel is the same when going from from babl PCS -> XYZ -> some linear RGB, as if you do XYZ -> some linear RGB. This matrix will be stored in the specific BablModel for this color space; and available in code paths for doing conversions to/from PCS or directly between such models.

It is only for CIE Lab and related spaces we end up with a longer sequence of conversions (the CIE color models are the type of spaces that need a bit more special treatment, which is why those color models have an implementation of XYZ to/from linear sRGB.). Most algorithms and editing is RGB centric; thus this is a fair compromise. The CIE Lab code if refactored could also be a single step away from the PCS.

Given that the choice of PCS, is any suitable RGB space. We are left with looking for other redeeming qualities to make a choice. A lot of - yes legacy; but we have code integrating with such libraries file formats and more; 8bit images around, and some 16bit images as well do use sRGB. And sRGB continues to be the recommended format on the web and elsewhere.

/pippin

On Fri, Oct 10, 2014 at 9:38 PM, Elle Stone wrote:

You cannot get from "sRGB as PCS" to LAB without first converting from "sRGB as PCS" to XYZ. LAB is a mathematical transform of XYZ, not sRGB.

This is the normal path from User_RGB to LAB: User_RGB -> XYZ -> LAB. Two conversions.

You want to take this path, yes? User_RGB -> XYZ -> "sRGB as PCS" -> XYZ -> LAB. Four conversions, going through XYZ twice.

Why is the second path preferable?

Forget about CIE Lab, and consider RGB spaces - which is what we are most concerned about. When transforming between linear RGB spaces there will be no conversion to XYZ. In the end when things are rigged up propertly, this will be performed in a single step with a single transformation matrix; which is cached nearby in the code doing the copy.

From the mental model of how babl and BablFormats are used; all of this is however implementation details. The important thing is that a pointer to a single unique BablFormat is all we need to be sure about the colorimetric values of the pixel. Which is the role of an ICC profile in color management between applications and devices. We can combine this with other BablFormats that we want to read or write the data in. As well as create buffers that store their content in any BablFormat.

Existing code written with assumptions of sRGB, whether in GIMP and GEGL that we control or in XPM, GTK, GDK, or elsewhere that has sRGB assumed will continue to work. We take the existing architecture which is following general guidelines of assuming sRGB where none is specified. This is what I mean by sRGB/the PCS being Celcius in the temperature analogy. A lot of the buffers that GIMP ends up for drawing its user interface are all things that are expected to be passed as sRGB data. (most bits of GTK outside actual image windows; which we should be communicating with the system compositor in opting out of global color corrections the it already should be doing of the pixels from sRGB->display profile.).

/Øyvind K.

Elle Stone (ellestone@ninedegreesbelow.com) wrote:

You cannot get from "sRGB as PCS" to LAB without first converting from "sRGB as PCS" to XYZ. LAB is a mathematical transform of XYZ, not sRGB.

This is the normal path from User_RGB to LAB: User_RGB -> XYZ -> LAB. Two conversions.

You want to take this path, yes? User_RGB -> XYZ -> "sRGB as PCS" -> XYZ -> LAB. Four conversions, going through XYZ twice.

[I am most likely talking about stuff that you already know, but it might be worth reiterating to keep the discussion understandable for people not that deep in the topic]

Note that - as long as we're talking about linear RGB spaces (which pure sRGB is not, but AFAIK we're talking about "linear RGB with the sRGB primaries" here) - all but the last conversions in your chain boil down to applying a matrix to a vector. You can easily multiply these matrices together to build a matrix that does the first three conversions in a single operation.

Some years ago I was working with a camera manufacturer to improve the image quality from the sensor. We ended up doing the following sequence of operations:

* input is RGB data specific to the sensor used * this gets transformed to XYZ
* conversion into the cone response domain (Bradford) * shift the white point (for white balance) * via Bradford back to XYZ
* conversion to sRGB (which was the desired output format)

We by no means had enough computing power available to do all these steps individually. But it also wasn't necessary since they could be performed within a FPGA with a single matrix multiplication and a lookup table (for the gamma aspect of sRGB).

But despite talking about a single conversion it is logically composed from a series of conversions and it is important to keep that in mind to get a clear understanding what is actually happening.

We must not confuse the logical conversion chain with the computation that is actually performed.

Bye, Simon

simon@budig.de              http://simon.budig.de/

On Sat, Oct 11, 2014 at 1:18 AM, Elle Stone wrote:

I really don't want to forget about LAB. The plan is that "sRGB as PCS" will be used for "something". I'm trying to figure out what exactly "something" covers. So I have two specific questions. The first question is about converting to LAB. The second question (which I haven't asked yet) has to do with Y.

We will try to do what makes sense and helps us achieve what we need to achieve efficiently; while keeping what works well, working well.

"sRGB as PCS" is linear gamma unbounded sRGB. I think it's reasonable to ask why a conversion to unbounded sRGB should be involved in a conversion from User_RGB to LAB.

For the same reason XYZ is involved (or not, depending on how the CMM does it) in an ICC workflow.

Existing code written with assumptions of sRGB, whether in GIMP and GEGL that we control or in XPM, GTK, GDK, or elsewhere that has sRGB assumed will continue to work. We take the existing architecture which is following general guidelines of assuming sRGB where none is specified.

Assigning sRGB to images with no embedded profile is done because you can't display images in an ICC profile color-managed workflow until an ICC profile is assigned. How images with no embedded profile are handled is irrelevant to the question of why a conversion from User_RGB to LAB needs to involve unbounded sRGB.

This is not about how images with no embedded profile are handled. sRGB derived 8bit (and to a lesser degree 16bit) formats are used for many other things than images with no embedded profile. These pixel formats are crucical for integrating with existing file formats and libraries; and we want these conversions to be as fast as possible - even if it might have an impact on the conversion speed for CIE Lab, though that does not have to be the case either. Choosing any PCS *but* linear sRGB would tend to make these important conversions slower.

I can move on to my question about Y and unbounded sRGB. But I still don't understand why unbounded sRGB should be involved in a conversion from User_RGB to LAB.

We will do what makes most sense and is neccesary when we get there, I suspect each RGB model with have an associated Y and YA model. Due to how the existing BablModels interact with components and vocabulary used to address them in babl; potential support for different TRCs is even vaguer; we'll know when we have more code.

Maybe we have more code by the time of LGM, if not that would be an excellent place to elaborate; until then I prefer IRC.

/pippin

On Sat, Oct 11, 2014 at 12:08 AM, Øyvind Kolås wrote:

You want to take this path, yes? User_RGB -> XYZ -> "sRGB as PCS" -> XYZ -> LAB. Four conversions, going through XYZ twice.

Why is the second path preferable?

Forget about CIE Lab

No way.

Alex

On Sat, Oct 11, 2014 at 1:41 PM, Elle Stone wrote:

As I have indicated before, the invitation is very kind. But not everyone is able to drop other obligations and go to LGM.

until then I prefer IRC.

Twice I tried to discuss problems with unbounded sRGB on IRC. It was neither pleasant nor productive.

That is an apt summary of this email exhange as well, neither pleasant nor productive - sorry. At least on IRC there is the chance of correcting misunderstanding before they've been published as books. The only reason I have responded in this thread is that "someone is wrong on the internet" and was spreading fundamental misunderstandings about how babl works as well as how we intended it to be used in GEGL in the future, I wish that time had been spent implementing it instead.

Many of the questions in your later e-mail have been responded to in other emails preceding your emails.

I find it ironic that the architecture that you question is the architectural foundation that ICC also is using. With similar constraints and performance characteristics.

/Øyvind

Please provide a specific example of an actual CMM in an ICC profile workflow that doesn't use XYZ for converting between RGB working spaces.

Please read simons post about matrix multiplication, in his camera example the data never exists as XYZ.

You falsely assume that 8-bit images are always sRGB images and that 16-bit integer images are probably sRGB images.

This is not being assumed, but it is a matter of fact that a lot of buffers are in these formats and we want to deal well with them.

formats are crucical for integrating with existing file formats and libraries;

File formats that only work with sRGB images should not impact color-managed image editing. Advise the user to convert to sRGB.

The data needs to be loaded into a GeglBuffer with a BablFormat that uniqely describes the color content. For 8bit sRGB with babl that has traditionally been "R'G'B' u8", in the roadmap in babl I even suggested that the buffers data is loaded into should be changed to be "sRGB:R'G'B' u8" for clarity even if it will continue to mean the same as "R'G'B' u8". And the chromaticity/working/target space should also be set to "sRGB:R'G'B'".

Unbounded linear gamma sRGB is not a Profile Connection Space.

Idiosyncratic redefinitions of well-established color management terms confuses people who don't understand ICC profile color management.

Idiosyncratic redefinitions of well-established color management terms makes it difficult for people who do understand ICC profile color management to communicate with the babl/GEGL devs.

There are differences between the internal implementation of a system and the public API. Calling the bablRGB a PCS, since that is the role it has in the internal implementation was an attempt at making you understand the architecture, and I guessed you did understand since you have been using the term as well. I thought you would understand how XYZ fills the same role in ICC. It is never called either XYZ nor PCS in the babl code. It is better if we call it bablRGB than linear sRGB which is an oxymoron.

Is there any point in my demonstrating how convoluted and unworkable it will be to convert to unbounded sRGB whenever Y is involved? Because if there isn't, I don't want to waste my time.

For a moment it seemed that perhaps unbounded sRGB was going to be dropped and we could move on to generalizing the code to use Y and XYZ taken from the user's chosen RGB working space
(http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html).

I was hinting at how a given set of chromaticities wouldn't be affecting single babl formats but change interpretation of also other formats when given a prefix.

You seem to challenge mention of sRGB to the extent that people have been championing linear workflows. While bablRGB will end up being an implementation detail that is an optimization. Babl will end up having _many_ different RGB spaces with associated grayscale format; at some point probably also associated non-linear spaces but that will have lower priority. Among these spaces will be a space called sRGB which behaves like the unprefixed formats. When we have these spaces. When we have these additional spaces - what I have suggested is that we then mark the operations which _are_ chromaticity dependent to operate in this space. I have also hinted at what we might want to do, or at least which things would be possible to do - including getting rid of all unprefixed formats, as well as the possibility that such things could be decided dynamically. There is a lot of code in GIMP that we intend to keep working as we move forward, the only way is by small incremental changes while keeping things working, changing as few assumptions as possible as move move along.

/Ø

On 11 October 2014 13:41, Elle Stone wrote:

On 10/10/2014 07:49 PM, Øyvind Kolås wrote:

This is not about how images with no embedded profile are handled. sRGB derived 8bit (and to a lesser degree 16bit) formats are used for many other things than images with no embedded profile.

You falsely assume that 8-bit images are always sRGB images and that 16-bit integer images are probably sRGB images.

No-one said always. sRGB is however the most common for 8-bit images.

These pixel

formats are crucical for integrating with existing file formats and libraries;

File formats that only work with sRGB images should not impact color-managed image editing. Advise the user to convert to sRGB.

Accurate UI colors is a desktop color management issue, entirely irrelevant to programming a color-managed image editor.

The application needs to interface with the desktop (windowing system). GIMP uses GTK+ for that, which uses Cairo APIs for rendering - which basically assumes 8-bit sRGB. I suspect that on X11/Linux these assumptions go deeper in the graphics stack as well. Yes, it is not right, but such is the state of things. We will have to improve it step-by-step.

Jon Nordby - www.jonnor.com

On Sun, Oct 12, 2014 at 8:41 AM, Elle Stone wrote:

On 10/11/2014 08:52 PM, Jon Nordby wrote: Please correct me if I misunderstood what you are saying. I think you are saying:

GIMP uses GTK+.

GTK+ uses Cairo APIs for rendering to the screen.

Cairo APIs assume 8-bit sRGB.

Therefore in GTK+ applications such as GIMP, images must be converted to sRGB before they can be displayed on the screen.

The same applies for most UI toolkits/APIs integrating with color management; the implementation that is unmanaged (or all!) content is to be presented in the framebuffer as sRGB and the desktop color management to compensate towards the monitor profile. Applications like GIMP, image viewers and similar - should be requesting that rectangular parts of the UI (image viewing areas and similar) be excepted from these conversions. Ideally we would be dealing differently with, no desktop CM and no display profile, no desktop CM (but have a display profile), desktop CMM without ability to opt out regions, and desktop CM with the ability to opt out regions.

sRGB goes even deeper in cairo, where all API entry points where individual colors are specified for stroking/filling/gradients is specified as floating point sRGB (with the TRC as well). Buffers we get from cairo for doing things like text rendering are 8bit sRGBA with sRGB TRC and pre-multiplied alpha. An annoyance for GEGL is that cairo is limited to 8bpc in its rasterization of vectors (by using a clever implementation choice; which makes things fast - but tricky to adapt for >8bit.).

Cairo is just one part of our eco-system which is following the guidelines of how to integrate with color management even if you do it badly; assume sRGB. Mostly everyone else tries to assume sRGB for consistency - when color management is considered hard; babl aims to make it easy and fast for GEGL to continue integrating with such code.

/pippin (btw, babl/docs/roadmap.txt has been slightly updated).

Am 12.10.2014 um 12:46 schrieb Øyvind Kolås :

On Sun, Oct 12, 2014 at 8:41 AM, Elle Stone wrote:

On 10/11/2014 08:52 PM, Jon Nordby wrote: Please correct me if I misunderstood what you are saying. I think you are saying:

GIMP uses GTK+.

GTK+ uses Cairo APIs for rendering to the screen.

Cairo APIs assume 8-bit sRGB.

Therefore in GTK+ applications such as GIMP, images must be converted to sRGB before they can be displayed on the screen.

Cairo is just one part of our eco-system which is following the guidelines of how to integrate with color management even if you do it badly; assume sRGB.

so that means, that specifying a monitor profile in GIMP’s preferences other than sRGB will result in displaying wrong colors. Or am I wrong?

I didn’t know that.

On systems with builtin desktop CM, like OS X, wouldn’t it be better to disable the choice of a monitor profile in GIMP at all, as long as cairo assumes SRGB?

Simone

On Sun, Oct 12, 2014 at 3:01 PM, Simone Karin Lehmann wrote:

Cairo is just one part of our eco-system which is following the guidelines of how to integrate with color management even if you do it badly; assume sRGB.

so that means, that specifying a monitor profile in GIMP’s preferences other than sRGB will result in displaying wrong colors. Or am I wrong?

I didn’t know that.

On systems with builtin desktop CM, like OS X, wouldn’t it be better to disable the choice of a monitor profile in GIMP at all, as long as cairo assumes sRGB?

This depends on how good GIMPs integration with the desktop CM is/will be, whether it is possible to opt the canvas and some other bits of the UI out of the sRGB assumption of the CM and pass uncorrected data through to the front buffer of the GPU for display. The reason for wanting to opt out only sub-rectangles rather than full windows, is to ensure that colors of buttons and other ui bits is the same in all applications. Without doing this one easily introduces color casts and more.

For instance Gnome Color Manager does; or at least used to, do this global correction of the front buffer towards being sRGB by altering the vCGT - gamma lookup tables in the GPU itself - with a little bit higher precision than 8bit. When fullscreen color management is done like that, for all pixels of the display - we do not even have a chance to opt out. When it is done with shaders and the possibility of masks for opting regions out, which are features that kwin/compiz have implementations of, the situation is different. GIMP needs to be able to adapt to various of these circumstances. Including the situation where nothing else on the system is doing color managment and the values GIMP provide for output gets passed through without anything else tweaking them.

/Øyvind