Rupert Weber (gimp@leguanease.org) wrote:

D50 vs D65
==========
Another question during transformation to Lab is, which illuminant or reference white to use.

That part, I don't quite understand yet. Does that depend on the source data, or simply on how the monitor is calibrated?

Well, Lab as a color space is not fully defined. Without further information it is not possible to have a Lab color calculated back to e.g. sRGB.

The problem is, that the "white" in Lab (100%, 0, 0) has no absolute color coordinates. You don't know if this is a reddish white of a light bulb or the blueish white of a fluorescent tube. In that sense Lab is not an absolute color space, unless you define what you actually mean by "white".

So if you have a sRGB image (where sRGB defines D65 as the white point) you can easily transform this into an Lab image, but you need to attach the information "the "white" is actually D65" to the result, to be able to meaningfully be able to transform the image back.

Maybe this helps a bit, Simon

Hi,

On 11.08.2010 19:19, Rupert Weber wrote:

PAL/SECAM vs sRGB
=================
While writing the Lab/LCH layer mode stuff, I wondered so far why the result is still slightly different from the current GEGL implementation of Color/Hue/Saturation/Value modes.

Now after taking a quick peek at the babl source, it seems that GEGL/babl assumes a PAL/SECAM RGB space as source (just like the Decompose plug-in.)

that sounds a bit strange to me. I thought PAL uses something like luminance channel plus 2 chroma channels? (See section 10.1 in [1] for a definition of PAL)

Possibly you've run into a linear light RGB vs. gamma-corrected RGB issue?!?

[..] -- barring actual color management the most reasonable assumption seems to be sRGB.

Me, too, thinks that sRGB is a reasonable assumption. If you want to Do It Right(tm), you will have to take the image's color profile into account. Since most, if not all 8-bit implementations of color operations are agnostic of the current color space, however, i think it's valid to postpone full color space support until GEGLized processing takes over.

D50 vs D65
==========
Another question during transformation to Lab is, which illuminant or reference white to use.

As far as layer modes are concerned, you are actually free to choose. If i understand correctly, you're on a chase for the 'best' 'color' layer mode anyway (where 'best' refers to some subjective quality). All other things being equal, it doesn't hurt to conform to the industry standard aka photoshop, which uses D50 [2].

Explanation from [2]: "" Lab values do not define absolute colors unless the white point is also specified. "" Often, in practice, the white point is assumed to follow a standard and is not "" explicitly stated

Which means, if you import or export Lab data you need to know the whitepoint to interpret to the data correctly. Layer modes, in contrast, are used purely internally, so the chosen whitepoint doesn't really matter here.

regards, yahvuu

[1] http://www.poynton.com/PDFs/coloureq.pdf [2] http://en.wikipedia.org/wiki/CIELAB

Disclaimer: I am not a color buff. Anybody who actually *knows* about that stuff, please chime in.

PAL/SECAM vs sRGB =================
While writing the Lab/LCH layer mode stuff, I wondered so far why the result is still slightly different from the current GEGL implementation of Color/Hue/Saturation/Value modes.

Now after taking a quick peek at the babl source, it seems that GEGL/babl assumes a PAL/SECAM RGB space as source (just like the Decompose plug-in.)

Considering that two different implementations use PAL/SECAM, I am wondering if there is a good reason for it and I just don't understand; or if maybe they just either copied from each other or happened to reference the same (limited) resource? After all, accurate color conversion information isn't abundant and was probably less so when that code was written.

sRGB has only been around since 1996. I suspect that the gimp version dates from before that, or at least before sRGB came into common use.

So far I'd say it's a bug -- barring actual color management the most reasonable assumption seems to be sRGB.

I don't think we want our color profiles to affect layer blending, so I think it is best that we choose a single color space and stick with it.

My intuition(possibly wrong) is that when LAB is only used as a temporary calculation space (as in layer blending) the RGB color space used will make only a very small difference in results as long as the RGB and LAB white points match up (ie RGB(255,255,255) => L*a*b*(100,0,0)).

This would leave speed, compatibility, and legacy support as the primary reason to choose a particular RGB color space.

D50 vs D65
==========
Another question during transformation to Lab is, which illuminant or reference white to use.

That part, I don't quite understand yet. Does that depend on the source data, or simply on how the monitor is calibrated?

You would not use the monitor white point, but you might want to use the white point of the image's color space or D50 depending on what you are trying to accomplish.

For a convenient color space to do math in use the source image's white point.
For data interchange use D50 (as photoshop and ICC profiles do).

Jay Cox jaycox@gimp.org

On 12 August 2010 03:19, Rupert Weber wrote:

Disclaimer: I am not a color buff. Anybody who actually *knows* about that stuff, please chime in.

I'm hardly a color buff either, but I'm going to chime in with a related query:

My understanding of GEGL (and, I assume, a fully GEGL-based GIMP) is that colors will be represented internally as linear-light RGB(A) structures. Given that (and please correct me if I'm already veering off track), how are the red, green and blue illuminants defined? Are they "virtual colors" that lie far enough outside the visible gamut that they can completely contain it? Or are they something else, like standard sRGB illuminants, or illuminants related to the color-space defined for the image being edited?

Apologies if this is all laid out in a road-map or API document somewhere - I've looked and come up blank.

Regards, Ed.

On 12.08.2010 01:17, Edward Coffey wrote:

My understanding of GEGL (and, I assume, a fully GEGL-based GIMP) is that colors will be represented internally as linear-light RGB(A) structures.

yep. scRGB is the color space of choice according to gegl.org.

(I don't know wether that's the final answer regarding GEGL usage within GIMP -- i haven't found any discussion about this.)

Given that (and please correct me if I'm already veering

off track), how are the red, green and blue illuminants defined?

color primaries are the same as sRGB [http://en.wikipedia.org/wiki/Scrgb].

regards, yahvuu

On 12 August 2010 00:17, Edward Coffey wrote:

My understanding of GEGL (and, I assume, a fully GEGL-based GIMP) is that colors will be represented internally as linear-light RGB(A) structures. Given that (and please correct me if I'm already veering off track), how are the red, green and blue illuminants defined? Are they "virtual colors" that lie far enough outside the visible gamut that they can completely contain it? Or are they something else, like standard sRGB illuminants, or illuminants related to the color-space defined for the image being edited?

As yahvuu says, they are the sRGB primaries.

You don't need to worry that the sRGB gamut is rather small since, because GEGL is using float, it can represent values outside the gamut as less than 0 or greater than 1.

I suppose it also means that GEGL will be D65 rather than D50, since [1, 1, 1] (gegl white) will be D65 white.

Photoshop (I think) uses D50 because the print world has traditionally used D50. This was because prints could be viewed in a variety of lighting conditions from daylight (D65) to Tungsten (about D35). D50 is a convenient half-way point for trying to make something that'll look OK in both.

Scientific colorimetry has always been D65. sRGB picked D65 as it's much closer to the D90 or so of most CRT tubes. .

John

Rupert Weber wrote:

D50 vs D65
==========
Another question during transformation to Lab is, which illuminant or reference white to use.

The whole point of L*a*b* as a color adjustment space, is that 100,0,0 is the white that the observer is adapted to, ie. RGB = 100%, 100%, 100%. That's why you feed the white point into the function that converts XYZ to L*a*b*.

D65 is the actual white point of sRGB, but since ICC PCS (Profile Connection Space) has a D50 white, an sRGB ICC profile throws in a chromatic adaptation transform from D65 to D50.

So there are two different ways you might choose to convert from sRGB to L*a*b* :

1) Convert from sRGB to XYZ using the sRGB space primaries, and feed D65 in as the L*a*b* white point.

2) Convert from sRGB to D50 adapted XYZ using an sRGB ICC profile, and feed D50 in as the L*a*b* white point.

[Note that, just to add some complexity, a properly ICC based color managed system would allow the RGB to L*a*b* conversion to choose the conversion intent, and might declare the "Lab space" to be ICC PCS L*a*b*, which will have a fixed D50 white reference.]

Graeme Gill.

Rupert Weber wrote:

(Then again, nobody complained so far and probably nobody would ever notice if we did it Right(tm)...)

You've got a catch 22 situation: If Gimp doesn't handle color conversions accurately, then noone interested in accurate color transforms will use it, hence you will get no complaints about not doing in Right. So if you want to persuade people who value accurate and reliable color transformations to use Gimp, you need to do it Right, otherwise they will continue to use something else. (I certainly can't use Gimp in my work, which revolves around checking color space transformations.)

Graeme Gill.

On 12.08.2010 13:09, Rupert Weber wrote:

On 08/11/2010 11:20 PM, yahvuu wrote:

Me, too, thinks that sRGB is a reasonable assumption. If you want to Do It Right(tm), you will have to take the image's color profile into account. Since most, if not all 8-bit implementations of color operations are agnostic of the current color space, however, i think it's valid to postpone full color space support until GEGLized processing takes over.

I agree. But I considered adding a reserved parameter to the functions, so we have the option to later add color management support without breaking binary compatibility of 3rd party plug-ins.

As far as layer modes are concerned, you are actually free to choose. If i understand correctly, you're on a chase for the 'best' 'color' layer mode anyway (where 'best' refers to some subjective quality).

Well, yes for now. But the conversion routines go into the colorspace lib and may be used by plug-ins for who knows what. (like the Decompose/Compose plug-in.) Then it might become relevant.

(Then again, nobody complained so far and probably nobody would ever notice if we did it Right(tm)...)

only the brave ones who do 8-bit processing with non-sRGB images would notice that the four 'color' layer modes try the behave the same regardless of working color space...

it's mostly a matter of proper documentation, i think.

For the library: if you add a whitepoint parameter for the conversion routine, that's fine, i think (left alone side-effects like performance penalty etc). If a fixed value gets used, document it, so plug-ins know what they use.

For the layer-modes: The myriads of possiblities should not clutter the UI, so i think there was consensus that you are free to choose the 'best' formula for the new 4 layer modes. On the surface these are simply labelled 'Color' etc, nitty-gritty details are to be looked up in the documentation/src.

regards, yahvuu

PS: For the future, to make things complicated: - the scientific users mentioned in the product vision probably want to choose exactly one of the myriad of possible conversions. This is more a problem of a suitable user interface than of code bloat.

- A typical operation like sharpening luminance should not involve creating a new layer. One way to solve this could be to offer 'virtual color component channels', so one can work on a luminance channel -- analogous to working on the red 'physical color component channel'.

On 12.08.2010 12:52, Rupert Weber wrote:

Thanks a lot for all the input.

I have been using the matrices from http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html *) and thought I was doing sRGB/D65-to-Lab or sRGB/D50-to-Lab. But as I understand now, I was actually doing sRGB-to-Lab/D65 or /D50; while all the RGB spaces like AdobeRGB or sRGB have their own fixed implicit reference white.
Correct?

if you took gamma into account, then yes.

*) This is where the matrix used by babl and the Decompose plug-in is listed as "PAL/SECAM")

Never heard about that one, but that doesn't mean much :-)

As to babl and the Decompose plug-in: They should be updated to use sRGB conversion?

Regarding BABL: i've had a look at extensions/CIE.c and found conversion routines using linear light RGB with the sRGB primaries and white point -- that is scRGB. Everything fine here.

Now i'm not familier with BABL -- possibly i've checked at the wrong routines?

Regarding the Decompose plug-in: yes, that seems to use the PAL stuff. However, i'd be surprised if that makes a really big difference. What's more important, is that i couldn't find any routine which respects the gamma curve defined by sRGB.

regards, yahvuu

On 12.08.2010 14:46, Rupert Weber wrote:

On 08/12/2010 12:32 AM, James Cox wrote:

sRGB has only been around since 1996. I suspect that the gimp version dates from before that, or at least before sRGB came into common use.

That would certainly explain it.

I don't think we want our color profiles to affect layer blending, so I think it is best that we choose a single color space and stick with it.

I was wondering about that. Right now, that's the behavior.

But if you had two identical images differing only in color profile, should the same action (say, "increase contrast by 30%") deliver (a) the same visual result (gamut permitting), or (b) the same RGB values?

Wouldn't (a) be preferable, even if it is different from current behavior?

I guess pretty much everyone agrees that ideally the color profiles of imported images should neither affect layer blending nor any tool's characteristics.

The only sane way to achieve this is, like James says, to "choose a single color space and stick with it". This is possible with floating point processing (GEGL). All imported image data gets convert to, say scRGB, processing take places, and on export data may be converted to a different color space, if necessary.

Changing the working color space is a stop-gap solution for 8-bit processing, to work around excessive rounding losses, IMO. Now if you want to keep the operations' characteristics unchanged, you would have to put the conversion code inside of _each and every_ one of the tool, filter and blendmode routines.

So, i think GIMP should Get It Right for GEGL processing, while certain deviations of operations' characteristics are tolerable for 8-bit processing.

regards, yahvuu

yahvuu wrote:

I guess pretty much everyone agrees that ideally the color profiles of imported images should neither affect layer blending nor any tool's characteristics.

The whole point of color profiles is to describe how to interpret the device values as visual colors. So a tool that purports to work in a device independent colorspace, will (apart from gamut limits) have an effect that is not visually affected by the color profiles, but will of course have quite different affects on the device dependent values.

The only sane way to achieve this is, like James says, to "choose a single color space and stick with it". This is possible with floating point processing (GEGL). All imported image data gets convert to, say scRGB, processing take places, and on export data may be converted to a different color space, if necessary.

This would be ridiculous - by misinterpreting the device dependent colors you would be applying visual adjustments that differ between images, rather than being the same. The fact that you have applied uniform changes to the device values is not what you want, since the device values have different meanings for different device colorspaces.

Graeme Gill.

As an end user with no expertise in what is being said in this discussion I would like to ask three questions:

1. Why such focus on Lab, which seems to be problematic? Why can't YCbCr ITU R470 or R709 be used? They work without issues for luminance transfer in Decompose/Recompose. I'm sure there's a good answer and would like to understand it.

2. There's been a couple of mentions on this list about being able to do colour or luminance processing without a new layer. The Fade command already offers that: you run a command, then Fade at 100%, using the relevant transfer mode. Will the Fade command be updated with the new transfer methods?

3. If yes to the above, could someone look into making the Fade command available in more circumstances? At the moment, you run something thinking "I'll transfer this with Multiply" or whatever, only to discover that the Fade command is grayed out in the menu.

Charlie

On 12.08.2010 16:16, Graeme Gill wrote:

yahvuu wrote:

I guess pretty much everyone agrees that ideally the color profiles of imported images should neither affect layer blending nor any tool's characteristics.

The whole point of color profiles is to describe how to interpret the device values as visual colors. So a tool that purports to work in a device independent colorspace, will (apart from gamut limits) have an effect that is not visually affected by the color profiles, but will of course have quite different affects on the device dependent values.

yes, on purpose. If i had to put it to a motto, i'd say: "GIMP is about colors, not numbers."

The only sane way to achieve this is, like James says, to "choose a single color space and stick with it". This is possible with floating point processing (GEGL). All imported image data gets convert to, say scRGB, processing take places, and on export data may be converted to a different color space, if necessary.

This would be ridiculous - by misinterpreting the device dependent colors you would be applying visual adjustments that differ between images, rather than being the same. The fact that you have applied uniform changes to the device values is not what you want, since the device values have different meanings for different device colorspaces.

OK, here i'm silently presuming that GIMP is fed with absolute color data (meaning that the device color profile is known in case device dependend colors are given).

I consider working with device dependent files (that is, without knowing the profile) a very special case -- that would be like GIMP in 'number mode' instead of 'color mode'.

As you have explained before, it is necessary to be able to export device dependend files [1], but i wonder if GIMP really needs a special mode to deal with device dependent colors other than on import. I mean, if the device color profile isn't known, the data can't even be displayed without getting misinterpreted, left alone proccessed.

But i don't quite understand:

> This would be ridiculous - by misinterpreting the device dependent colors you > would be applying visual adjustments that differ between images,

why am i automatically misinterpreting the device dependent colors? If the device color profile is known, the conversion to scRGB should do no harm.

> The fact that you have applied uniform changes to the device > values is not what you want, since the device values have different meanings > for different device colorspaces.

how could one apply uniform changes 'in meaning' if the device color spaces are unknown?

regards, yahvuu

[1] https://lists.xcf.berkeley.edu/lists/gimp-developer/2010-March/024386.html .. and shame on me i missed to send a 'thank you!' for pulling things straight in that mail.

On 12.08.2010 17:20, yahvuu wrote:

than on import. I mean, if the device color profile isn't known, the data can't even be displayed
without getting misinterpreted, left alone proccessed.

oh, stop. Got it myself: e.g. for profiling the screen. Give me a second chance .-)

regards, yahvuu

2nd take:

On 12.08.2010 16:16, Graeme Gill wrote:

yahvuu wrote:

I guess pretty much everyone agrees that ideally the color profiles of imported images should neither affect layer blending nor any tool's characteristics.

The whole point of color profiles is to describe how to interpret the device values as visual colors. So a tool that purports to work in a device independent colorspace, will (apart from gamut limits) have an effect that is not visually affected by the color profiles, but will of course have quite different affects on the device dependent values.

yes, on purpose. If i had to put it to a motto, i'd say: "GIMP is about colors, not numbers."

The only sane way to achieve this is, like James says, to "choose a single color space and stick with it". This is possible with floating point processing (GEGL). All imported image data gets convert to, say scRGB, processing take places, and on export data may be converted to a different color space, if necessary.

This would be ridiculous - by misinterpreting the device dependent colors you would be applying visual adjustments that differ between images, rather than being the same. The fact that you have applied uniform changes to the device values is not what you want, since the device values have different meanings for different device colorspaces.

OK, here i'm silently presuming that GIMP is fed with absolute color data (meaning that the device color profile is known in case device dependend colors are given). In my regard, that is 'normal operation'.

I consider working with device dependent files (that is, without knowing the profile) a very special case -- that would be like GIMP in 'number mode' instead of 'color mode'.

If i play devil's advocate, i'd say that GIMP is an image editor, not a profiling/calibration application. GIMP itself doesn't need any calibration. Profiling printers and screens should be done by specialized applications.

Of course, it would be nice if GIMP had integrated support for such user needs, but strictly spoken, it can be done without GIMP (hope i'm right here -- i have no experience with profiling/calibration).

As you have explained before, GIMP can be part of the profiling tool chain if it is able to export device dependend files [1]. On the other end (import), i doubt that it is a good user interface to switch GIMP into 'screen calibration mode' by importing such an untagged, device dependent image. Wouldn't it be much better to have a dedicated UI for that? Say, Extras->Calibrate Monitor or the like..

The needs for calibration/profiling are important, but should not get in the way of everyday work.

But still i don't quite understand the following:

> This would be ridiculous - by misinterpreting the device dependent colors you > would be applying visual adjustments that differ between images,

why am i automatically misinterpreting the device dependent colors? If the device color profile is known, the conversion to scRGB should do no harm.

> The fact that you have applied uniform changes to the device > values is not what you want, since the device values have different meanings > for different device colorspaces.

how could one apply uniform changes 'in meaning' if the device color spaces are unknown?

regards, yahvuu

[1] https://lists.xcf.berkeley.edu/lists/gimp-developer/2010-March/024386.html .. and shame on me i missed to send a 'thank you!' for pulling things straight in that mail.

Graeme Gill wrote:

yahvuu wrote:

The only sane way to achieve this is, like James says, to "choose a single color space
and stick with it". This is possible with floating point processing (GEGL).
All imported image data gets convert to, say scRGB, processing take places, and on export
data may be converted to a different color space, if necessary.

This would be ridiculous - by misinterpreting the device dependent colors you
would be applying visual adjustments that differ between images, rather than
being the same. The fact that you have applied uniform changes to the device
values is not what you want, since the device values have different meanings
for different device colorspaces.

I think it is important to remember that these visual adjustments that we are applying are really just abstract mathematical formulas that we find visually useful. In some cases this is quite explicit (eg the multiply blend mode), and sometimes we try to hide this (eg contrast). The contrast tool does not add contrast to an image. The contrast tool runs the image through a particular mathematical formula. For every image where running an image through this formula results in an image with more apparent contrast I can show you an image where that formula will result in image with less apparent contrast. Device independent color space or not. That being said - the contrast tool could benefit from being color space aware.

What is important is that the result of all this math is accurately displayed on screen in a timely manner. Running every blending layer and adjustment through a CMS is counterproductive to this end. I think there is a role to play for device independent color adjustments, but they are the exception, not the rule.

If you need all your tools to be more consistent between images, then you can convert all your images to the same profile.

Graeme Gill.

yahvuu wrote:

OK, here i'm silently presuming that GIMP is fed with absolute color data (meaning
that the device color profile is known in case device dependend colors are given).

Sorry, your statement:

The only sane way to achieve this is, like James says, to "choose a single color space and stick with it". This is possible with floating point processing (GEGL).

was kind of ambiguous, and I took it to mean "single device dependent color space ..". If you actually mean "single device independent color space.." then of course my comment doesn't apply.

Graeme Gill.

James Cox wrote:

I think it is important to remember that these visual adjustments that we are applying are really just abstract mathematical formulas that we find visually useful. In some cases this is quite explicit (eg the multiply blend mode), and sometimes we try to hide this (eg contrast). The

You can of course use something like an RGB to L*a*b* conversion purely as a mathematical transformation to allow certain types of adjustments without regard to the color meaning, but my suggestion would be to never call the resulting space "Lab" if it is not a genuine device independent color space. You'll just confuse and mislead anyone who knows what that's meant to be.

Graeme Gill.

Date: Thu, 12 Aug 2010 18:58:45 +0200 From: yahvuu

OK, here i'm silently presuming that GIMP is fed with absolute color data (meaning that the device color profile is known in case device dependend colors are given). In my regard, that is 'normal operation'.

What is "absolute color data"?

On 12 August 2010 00:17, Edward Coffey wrote:

My understanding of GEGL (and, I assume, a fully GEGL-based GIMP) is that colors will be represented internally as linear-light RGB(A) structures. Given that (and please correct me if I'm already veering off track), how are the red, green and blue illuminants defined? Are they "virtual colors" that lie far enough outside the visible gamut that they can completely contain it? Or are they something else, like standard sRGB illuminants, or illuminants related to the color-space defined for the image being edited?

As yahvuu says, they are the sRGB primaries.

You don't need to worry that the sRGB gamut is rather small since, because GEGL is using float, it can represent values outside the gamut as less than 0 or greater than 1.

That sounds good in theory, but there will be some very sharp edges in practice. What does the UI for the curve tool look like when possible values are -FLOATMAX to +FLOATMAX. What does the contrast tool do with values above 1.0. When I blend some layers with multiply mode they can only get darker right?

I open up an image to make a small change to one corner. Why did other parts of my image change color slightly? Because Round tripping through a color profile is not lossless (some profiles are worse than others).

I have a picture of some flowers that I want to make as red as possible to print on my AdobeRGB1998 printer - Instead of adjusting to 1.0, 0, 0 I have to go to 1.1, -.03, -.07? Or are you converting it to my destination space and back again every time i make an edit?

You can hide the numbers entirely from the beginners. The experts can get used to anything. But the intermediate/enthusiasts are going to have a very hard time.

Adobe lightroom does something very similar, except it uses the ProPhoto RGB primaries. Lightroom can get away with this because it's usage is very different. It always receives image data with a nebulous a color space (data from the camera's sensor) and will always export the data to different color space. And people still complain about the internal color space...

Jay Cox
jaycox@gimp.org

On 13.08.2010 02:34, Robert Krawitz wrote:

Date: Thu, 12 Aug 2010 18:58:45 +0200 From: yahvuu

OK, here i'm silently presuming that GIMP is fed with absolute color data (meaning that the device color profile is known in case device dependend colors are given). In my regard, that is 'normal operation'.

What is "absolute color data"?

That was thought as "color data that is defined in an absolute color space, or can be unambiguously transformed into such a color space". Perhaps a better term is 'unambiguous color data'.

I'm still searching for a good term which shortens "colors that are specified using device independent color specification -- that is either by using a device independent color space, or by using a device dependent color space plus the corresponding device color profile".

regards,
yahvuu

On 13 August 2010 02:57, James Cox wrote:

You don't need to worry that the sRGB gamut is rather small since, because GEGL is using float, it can represent values outside the gamut as less than 0 or greater than 1.

That sounds good in theory, but there will be some very sharp edges in practice.  What does the UI for the curve tool look like when possible values are -FLOATMAX to +FLOATMAX.  What does the contrast tool do with values above 1.0.  When I blend some layers with multiply mode they can only get darker right?

scRGB actually does define a range, -0.5 to +7.5, according to wikipedia, so tools like the levels dialog are not totally in the dark.

I open up an image to make a small change to one corner. Why did other parts of my image change color slightly?  Because Round tripping through a color profile is not lossless (some profiles are worse than others).

Well, that's certainly true. Though open/edit/save, at least for JPEGs, will always change the image slightly, even in applications that support device space editing. It's a question of how significant the differences are.

John

On Fri, Aug 13, 2010 at 9:06 AM, wrote:

On 13 August 2010 02:57, James Cox wrote:

You don't need to worry that the sRGB gamut is rather small since, because GEGL is using float, it can represent values outside the gamut as less than 0 or greater than 1.

That sounds good in theory, but there will be some very sharp edges in practice.  What does the UI for the curve tool look like when possible values are -FLOATMAX to +FLOATMAX.  What does the contrast tool do with values above 1.0.  When I blend some layers with multiply mode they can only get darker right?

scRGB actually does define a range, -0.5 to +7.5, according to wikipedia, so tools like the levels dialog are not totally in the dark.

That is just due to the encoding chosen, (fitting in 16bit) GEGL uses normal IEEE floats just like EXR and thus has the range -FLOATMAX to +FLOATMAX supporting HDR buffers with huge range. Thus the "native" pixel format used by GEGL isnt directly scRGB, but IEEE floating point RGB(A) with linear light and primaries like in sRGB.

Some additional comments about color management in GEGL, confirming what has already been stated/suggested. GeglBuffers have a specified pixel-format, as defined by babl, babl's pixel formats are (at least supposed to be) well defined and accurate conversions between both precisions and color models. Thus once data is in a babl governed pixel format the color values should already be well defined. If the color space of a source image is in a device-dependent color space it either is converted upon load to for instance "RGBA float" or a dynamically created babl pixel format with an attached/referenced ICC profile and lcms2 powered conversions would be used.

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. For many operations "RGBA float", linear light RGBA in 32bit floating point is good. For other operations "RaGaBaA float" is good this being the same as "RGBA float" but with pre-multiplied alpha, this is used by most compositing operators. Some operations might prefer to operate in (and generate) "CIE Lab float" buffers, like the color layer mode. If the previous operation generated buffer data in the preferred format of our current operation the conversion will be a no-op or babl will fall back to a memcpy (in cases where direct access to underlying tiles is not possible). The net-effect of this is that GEGL should provide a color managed result that can ultimately be converted/separated according to a target profile.

To force operation in a non-color managed, paint by numbers-mode you would have to force the format of a buffer, casting a device-dependent pixel format to "RGBA float" before the operations - and casting it back to the device-dependent format after the device-dependent processing is done.

On Thu, Aug 12, 2010 at 2:39 PM, Rupert Weber wrote:

Regarding BABL: i've had a look at extensions/CIE.c and found conversion routines using linear light RGB with the sRGB primaries and white point -- that is scRGB. Everything fine here.

Now i'm not familier with BABL -- possibly i've checked at the wrong routines?

What I found was conv_rgbF_xyzF() in extensions/gggl-lies.c But I'm just as unfamiliar with babl, so I might be the one who looked at the wrong place.

That code is never used (gggl-lies contains a bunch of conversions, some which are expected to fail - but only the correct ones pass the runtime regression testing all conversions are subject to). CIE.c in the same directory is what is used.

/Øyvind K.

On Fri, Aug 13, 2010 at 4:17 PM, Rupert Weber wrote:

On 08/13/2010 01:57 PM, Øyvind Kolås wrote:

That code is never used (gggl-lies contains a bunch of conversions, some which are expected to fail - but only the correct ones pass the runtime regression testing all conversions are subject to). CIE.c in the same directory is what is used.

Thanks.
The comment in the code also explains the current difference: /* The gamma related code has been removed since we do our * calculations in linear light. [...]

When I remove gamma correction, I get the same result with layermodes as GEGL.

Does that mean GEGL should do the gamma correction before passing the RGB data to babl?

Only babl is doing color model, gamma, bit depth etc conversions, never GEGL. If the data is "R'G'B'A float" babl would take care of making it linear before doing the real conversion. Though that is unlikely as GEGL prefers to pass around "RGBA float" or "RaGaBaA float" data which is linear.,

I do not know the details, but I suspect GIMP is lying about most buffers being passed to GEGL. It probably is lying and pretending that sRGB data is linear.. by passing pixel data to GEGL as "RGBA u8" instead of "R'G'B'A u8" ... to maintain rendering compatibility with the legacy GIMP core, layer modes etc. which all assume compositing done in gamma corrected rather than using linear light.

/Øyvind K.

jcupitt@gmail.com wrote

I open up an image to make a small change to one corner. Why did other parts of my image change color slightly?  Because Round tripping through a
color profile is not lossless (some profiles are worse than others).

Well, that's certainly true. Though open/edit/save, at least for JPEGs, will always change the image slightly, even in applications that support device space editing. It's a question of how significant the differences are.

A professional will do anything possible to avoid going through multiple jpeg compression steps, and certainly wouldn't use software that required it as part of the workflow.

Converting to/from synthetic color spaces like sRgb and AdobeRGB will be lossless aside from very minor numerical rounding issues.

Converting to/from real world measured color profiles will result in visible differences after the first round trip, and will generally be unusable without significant correction after 2 or 3.

Jay Cox jaycox@gimp.org

yahvuu wrote:

That was thought as "color data that is defined in an absolute color space, or can be unambiguously transformed into such a color space". Perhaps a better term is 'unambiguous color data'.

Unfortunately, due to the adaptability of human vision, there is really no such thing as an absolute unambiguous color space.

But for practical purposes there is something that everyone uses, and that is the CIE standard observer tri-stimulus space, XYZ.

But note there are still many subtleties. The most popular XYZ spaces come in two flavours, 2 degree and 10 degree, referring to the viewing angle, since we have different type of color sensitive cells in the central and peripheral viewing regions of our eyes. For practical use, there is often the assumption that the viewer is perfectly adapted to the white point of the scene (ICC relative colorimetric), and XYZ is typically an absolute coordinate system, that doesn't normalise to any white point, hence the use of chromatic adaptation transforms. CIE XYZ assumes a set of standard viewing conditions (absolute brightness level, surround color etc.), whereas the real world probably has different viewing conditions, hence CIECAM02 etc.

ICC device profiles codify a transformation from device colorspaces to/from PCS (Profile connection space), which is defined in terms of CIE XYZ.

Psudo device independent spaces such as scRGB, sRGB, Adobe RGB are defined in terms of XYZ too. Note that there is some controversy of how to handle the white point adaptation to these spaces though, although this is only of relevance in specialised applications where absolute XYZ is required.

Graeme Gill.

James Cox wrote:

Converting to/from synthetic color spaces like sRgb and AdobeRGB will be lossless aside from very minor numerical rounding issues.

Note that this is not true if you exceed the gamut of these two spaces, and the resulting device values are clipped to the range 0 - 1.

Graeme Gill.