A discussion about color management in Inkscape
Hello List,
a while ago I filed a bug in launchpad about how Inkscape treats color spaces and does its display color management (https://bugs.launchpad.net/inkscape/+bug/1457053).
As requested by Tavmjong I wrote up some further explanations in the hope that it helps people understand the problem and maybe start some discussion.
First of all I beg your pardon for the wall of text. If you know about color spaces just skip the "Theory" part.
In the following description I will only talk about RGB color spaces. For things like CMYK the same reasoning applies but I want to keep it simple. For the sake of readability. I will also simplify a terrible lot to keep this beginner friendly and easy to understand. Like, seriously simplify. No need to point that out. I am also aware that some of the limitations might be coming from the SVG specs or are at least implied in there (like the mandatory blending in gamma corrected or linear sRGB).
Theory
When we talk about (RGB, see above) colors we often only mention three numbers representing the value for each of the red, green and blue channel. In general 0 means "nothing" and 255 (8 bit values) or 1.0 (float values) means "full power". I will use the float notation here since it's easier to calculate in the head. Thus, something like (1, 0, 0) means "the reddest red" and (1, 1, 1) is "white".
Now, there is a problem once you want to display such a color: What does "full power" or "the reddest red" actually mean? That's where color spaces come into play. They define a set of "primaries" that tell us what "red", "green" and "blue" actually mean. They are defined in absolute, real world means (most often in XYZ) that directly relate to specific wavelengths of light and precisely define a color that can be displayed. With that knowledge it's possible to say that (1, 0, 0) is not just some reddest red, but what it looks exactly like. Every other color inside the [0..1] range per channel can thus be defined, too. Some popular color spaces are sRGB and AdobeRGB in the RGB world. The CMYK world has things like "ISO Coated v2".
Of course there is more than just one color space and most have different primaries. The colors that can be described with a given set of primaries is called the "gamut" of a color space – not to be confused with the color space's "gamma"! We will ignore the latter.
Now that we know that the same triplet of numbers does mean something different in different color spaces we also understand that the numbers alone are meaningless without a color space. Since there is a terribly large number of images – both raster and vector – without any color profile information attached there is the common default of assuming sRGB.
When looking at articles about color spaces there are almost always images of a horse shoe formed colorful diagram with a triangle on top (like https://commons.wikimedia.org/wiki/File:CIE1931xy_gamut_comparison.svg). The background horse shoe represents all possible colors a typical human can see while the corners of the triangle are just the aforementioned primaries. The area of the triangle covers the colors that the colorspace can display*. With the AdobeRGB triangle being bigger than the sRGB one (and completely covering it) we can easily see that AdobeRGB contains colors that are not expressible in sRGB.
Besides these well known and standardized color spaces used to define colors in images there are also device color spaces that describe what colors some physical appliance can display. For now we will concentrate on monitor profiles since they are also RGB but of course also printers with four or even more colors can be measured and their primaries be determined. See the SWOP CMYK gamut in the sample image for a typical result of that. Back in the days of CRTs there was that prototypical monitor that exactly covered the sRGB color space – it's where it originated from. Nowadays with LCD displays and all that diverging technologies there isn't one typical display profile any longer. It turns out that most laptops and consumer grade displays cover less than sRGB while some high end monitors reach AdobeRGB or even wider gamuts. Therefore it's important to have proper color management in place so that the (1, 0, 0) you put into an image looks the same everywhere and not like an orange on some screens and a fire truck on another.
Current state of Inkscape
I have to admit that it's a while since I looked at the relevant code so my memory might be missing some details, but I am quite sure that the general picture I'm going to paint is in the right ballpark.
When Inkscape displays "normal" colors they are untagged, 8 bit values. So it's just something of the form (255, 0, 255) for a nice magenta. According to the SVG specs (http://www.w3.org/TR/SVG/color.html) this is implicitly assumed to be sRGB. Using the CMS mode of the Fill&Stroke dialog the user can also specify the color space to be something else, for example AdobeRGB. While the value set in that mode gets propagated to the SVG as-is and be tagged with its color space, internally it will be converted to sRGB. When the user also specified a display profile the result of the renderer will in the end be transformed from sRGB (that's what all the colors Inkscape works with are) to the display profile.
Problems
While in theory this seems to be a sound way to deal with colors – transforming everything to sRGB as the internal working space – it poses a few problems in practice. First and foremost there is the usage of 8 bit values. It doesn't allow very fine steps between tonalities. And the bigger the color space's gamut gets the worse it becomes. That is especially true when doing blending in linear space and not gamma corrected (never mind that detail, it's not the important part here). Just look at the diagram again. The same number of steps (255 in case of 8 bit values) have to stretch a wider range of real world colors, so every intermediate step gets bigger. Another problem with 8 bit colors is that there is nothing below 0 and nothing above 255. At first that might not look like a problem, after all, (255, 0, 0) is the reddest red. There is nothing more red, so why think about numbers that are bigger? Well, because as we have seen earlier, it's only the reddest red in its own color space. When looked at it in any bigger color space it's just an average red, there are redder reds. Therefore the transformation of colors into sRGB will leave wrong results when anything that is not inside the sRGB gamut is being transformed to it and at the same time clipped to the 8 bit range. The result can't be mapped back to the original color any longer. Even when the display is able to cover all the AdobeRGB colors and the user specifies the colors in that color space the displayed results will map everything outside of the sRGB gamut to its inside (there are several way to do that clamping, you can just cut the values off, scale them nicely, ... but at the end of the day they are not what they used to be).
To show the results of this clamping have a look at https://launchpadlibrarian.net/206984719/canvas_cms.png. Every row contains the same color value (shown on the left) four times, just tagged with different color spaces. So the first row should show the reddest red in AdobeRGB, sRGB and Laptop (some color space SMALLER than sRGB). We will ignore the GRB column, it's just there to show that color management was actually turned on. We notice that the first two columns look the same though. The reason is the clamping Inkscape does. The reddest red of AdobeRGB (i.e., its red primary) is far outside of sRGB's gamut. So Inkscape clamps the color and moves it to the closest sRGB contains: the reddest red sRGB knows. The same happens for green and blue. Once that happened every further step won't distinguish between the colors that once were very different and no matter what display profile is set the result will look the same. Because it is. Now for the third column. The Laptop profile has a smaller gamut than sRGB so when converting its primaries to sRGB they can be represented in the 8 bit range and are shown correctly in the resulting image.
A better world
All of this isn't that great for anything that is supposed to have correct colors and not be limited to sRGB. That might be less of a concern for Web graphics, but once you think about printing (most CMYK profiles are not inside the sRGB gamut) or even just seeing your work on a good monitor you have a problem.
The first step would be to get rid of the 8 bit limitation. Not only would that allow for smoother gradients (remember that step size? With float they become virtually arbitrarily small!) but floats also allow to transform colors to a smaller gamut without clipping them since the values can be bigger than 1.0. Of course, all color math has to be checked if it would still work with values bigger than "full power" and there are cases where it will fail. Thus as a second step it would be helpful to either replace sRGB with something bigger for the internal working space (not exactly what the SVG specs allow :-() or maybe even keep all colors in their original color space and only do transformations where needed. Since there are even problems when doing some computations in a gamut that can express all colors but isn't the original one it might even be a good idea to let the user specify a color space of the whole document so that all colors that are not tagged are treated as that color space instead of sRGB, i.e., specify the working space (again, not what the SVG specs call for). For documents not mixing colors of different color spaces that might be the best solution – just take all colors as-is, handle them like Inkscape already does (with the exception that it should really really do it in float and not 8 bit) and in the end convert from the document working space to the display color space.
* Actually this is just the colors with maximum saturation, the set of all colors isn't a triangle but skewed box in 3D space. In order to compare color spaces it's enough to look at this projection though.
Thanks for reading Tobias
Great explain! I hope we use doubles in the future.
El vie, 09-10-2015 a las 18:42 +0200, Tobias Ellinghaus escribió:
Hello List,
a while ago I filed a bug in launchpad about how Inkscape treats color spaces and does its display color management (https://bugs.launchpad.net/inkscape/+bug/1457053).
As requested by Tavmjong I wrote up some further explanations in the hope that it helps people understand the problem and maybe start some discussion.
First of all I beg your pardon for the wall of text. If you know about color spaces just skip the "Theory" part.
In the following description I will only talk about RGB color spaces. For things like CMYK the same reasoning applies but I want to keep it simple. For the sake of readability. I will also simplify a terrible lot to keep this beginner friendly and easy to understand. Like, seriously simplify. No need to point that out. I am also aware that some of the limitations might be coming from the SVG specs or are at least implied in there (like the mandatory blending in gamma corrected or linear sRGB).
Theory
When we talk about (RGB, see above) colors we often only mention three numbers representing the value for each of the red, green and blue channel. In general 0 means "nothing" and 255 (8 bit values) or 1.0 (float values) means "full power". I will use the float notation here since it's easier to calculate in the head. Thus, something like (1, 0, 0) means "the reddest red" and (1, 1, 1) is "white".
Now, there is a problem once you want to display such a color: What does "full power" or "the reddest red" actually mean? That's where color spaces come into play. They define a set of "primaries" that tell us what "red", "green" and "blue" actually mean. They are defined in absolute, real world means (most often in XYZ) that directly relate to specific wavelengths of light and precisely define a color that can be displayed. With that knowledge it's possible to say that (1, 0, 0) is not just some reddest red, but what it looks exactly like. Every other color inside the [0..1] range per channel can thus be defined, too. Some popular color spaces are sRGB and AdobeRGB in the RGB world. The CMYK world has things like "ISO Coated v2".
Of course there is more than just one color space and most have different primaries. The colors that can be described with a given set of primaries is called the "gamut" of a color space – not to be confused with the color space's "gamma"! We will ignore the latter.
Now that we know that the same triplet of numbers does mean something different in different color spaces we also understand that the numbers alone are meaningless without a color space. Since there is a terribly large number of images – both raster and vector – without any color profile information attached there is the common default of assuming sRGB.
When looking at articles about color spaces there are almost always images of a horse shoe formed colorful diagram with a triangle on top (like https://commons.wikimedia.org/wiki/File:CIE1931xy_gamut_comparison.sv g). The background horse shoe represents all possible colors a typical human can see while the corners of the triangle are just the aforementioned primaries. The area of the triangle covers the colors that the colorspace can display*. With the AdobeRGB triangle being bigger than the sRGB one (and completely covering it) we can easily see that AdobeRGB contains colors that are not expressible in sRGB.
Besides these well known and standardized color spaces used to define colors in images there are also device color spaces that describe what colors some physical appliance can display. For now we will concentrate on monitor profiles since they are also RGB but of course also printers with four or even more colors can be measured and their primaries be determined. See the SWOP CMYK gamut in the sample image for a typical result of that. Back in the days of CRTs there was that prototypical monitor that exactly covered the sRGB color space – it's where it originated from. Nowadays with LCD displays and all that diverging technologies there isn't one typical display profile any longer. It turns out that most laptops and consumer grade displays cover less than sRGB while some high end monitors reach AdobeRGB or even wider gamuts. Therefore it's important to have proper color management in place so that the (1, 0, 0) you put into an image looks the same everywhere and not like an orange on some screens and a fire truck on another.
Current state of Inkscape
I have to admit that it's a while since I looked at the relevant code so my memory might be missing some details, but I am quite sure that the general picture I'm going to paint is in the right ballpark.
When Inkscape displays "normal" colors they are untagged, 8 bit values. So it's just something of the form (255, 0, 255) for a nice magenta. According to the SVG specs (http://www.w3.org/TR/SVG/color.html) this is implicitly assumed to be sRGB. Using the CMS mode of the Fill&Stroke dialog the user can also specify the color space to be something else, for example AdobeRGB. While the value set in that mode gets propagated to the SVG as-is and be tagged with its color space, internally it will be converted to sRGB. When the user also specified a display profile the result of the renderer will in the end be transformed from sRGB (that's what all the colors Inkscape works with are) to the display profile.
Problems
While in theory this seems to be a sound way to deal with colors – transforming everything to sRGB as the internal working space – it poses a few problems in practice. First and foremost there is the usage of 8 bit values. It doesn't allow very fine steps between tonalities. And the bigger the color space's gamut gets the worse it becomes. That is especially true when doing blending in linear space and not gamma corrected (never mind that detail, it's not the important part here). Just look at the diagram again. The same number of steps (255 in case of 8 bit values) have to stretch a wider range of real world colors, so every intermediate step gets bigger. Another problem with 8 bit colors is that there is nothing below 0 and nothing above 255. At first that might not look like a problem, after all, (255, 0, 0) is the reddest red. There is nothing more red, so why think about numbers that are bigger? Well, because as we have seen earlier, it's only the reddest red in its own color space. When looked at it in any bigger color space it's just an average red, there are redder reds. Therefore the transformation of colors into sRGB will leave wrong results when anything that is not inside the sRGB gamut is being transformed to it and at the same time clipped to the 8 bit range. The result can't be mapped back to the original color any longer. Even when the display is able to cover all the AdobeRGB colors and the user specifies the colors in that color space the displayed results will map everything outside of the sRGB gamut to its inside (there are several way to do that clamping, you can just cut the values off, scale them nicely, ... but at the end of the day they are not what they used to be).
To show the results of this clamping have a look at https://launchpadlibrarian.net/206984719/canvas_cms.png. Every row contains the same color value (shown on the left) four times, just tagged with different color spaces. So the first row should show the reddest red in AdobeRGB, sRGB and Laptop (some color space SMALLER than sRGB). We will ignore the GRB column, it's just there to show that color management was actually turned on. We notice that the first two columns look the same though. The reason is the clamping Inkscape does. The reddest red of AdobeRGB (i.e., its red primary) is far outside of sRGB's gamut. So Inkscape clamps the color and moves it to the closest sRGB contains: the reddest red sRGB knows. The same happens for green and blue. Once that happened every further step won't distinguish between the colors that once were very different and no matter what display profile is set the result will look the same. Because it is. Now for the third column. The Laptop profile has a smaller gamut than sRGB so when converting its primaries to sRGB they can be represented in the 8 bit range and are shown correctly in the resulting image.
A better world
All of this isn't that great for anything that is supposed to have correct colors and not be limited to sRGB. That might be less of a concern for Web graphics, but once you think about printing (most CMYK profiles are not inside the sRGB gamut) or even just seeing your work on a good monitor you have a problem.
The first step would be to get rid of the 8 bit limitation. Not only would that allow for smoother gradients (remember that step size? With float they become virtually arbitrarily small!) but floats also allow to transform colors to a smaller gamut without clipping them since the values can be bigger than 1.0. Of course, all color math has to be checked if it would still work with values bigger than "full power" and there are cases where it will fail. Thus as a second step it would be helpful to either replace sRGB with something bigger for the internal working space (not exactly what the SVG specs allow :-() or maybe even keep all colors in their original color space and only do transformations where needed. Since there are even problems when doing some computations in a gamut that can express all colors but isn't the original one it might even be a good idea to let the user specify a color space of the whole document so that all colors that are not tagged are treated as that color space instead of sRGB, i.e., specify the working space (again, not what the SVG specs call for). For documents not mixing colors of different color spaces that might be the best solution – just take all colors as-is, handle them like Inkscape already does (with the exception that it should really really do it in float and not 8 bit) and in the end convert from the document working space to the display color space.
- Actually this is just the colors with maximum saturation, the set
of all colors isn't a triangle but skewed box in 3D space. In order to compare color spaces it's enough to look at this projection though.
Thanks for reading Tobias
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, Oct 09, 2015 at 07:22:25PM +0200, Jabiertxo Arraiza Cenoz wrote:
Great explain! I hope we use doubles in the future.
Probably not. Doubles would increase memory consumption for pixel data by a factor of 8, for no real benefit. More likely would be to either use a fixed point representation (e.g. s1.14 to allow each component to cover colours outside srgb's [0,1] range) or a standard floating point format like float16 (half). Another candidate would be rgbx high dynamic range colour with some work to allow out of gamut colours.
It might be sufficient to recompile our existing pixel pipelines with u16s with some transform code for mapping to display rgb to provide headroom.
Tobias, Are we happy with staying with sRGB as our reference colour space?
njh
El vie, 09-10-2015 a las 18:42 +0200, Tobias Ellinghaus escribió:
Hello List,
a while ago I filed a bug in launchpad about how Inkscape treats color spaces and does its display color management (https://bugs.launchpad.net/inkscape/+bug/1457053).
As requested by Tavmjong I wrote up some further explanations in the hope that it helps people understand the problem and maybe start some discussion.
First of all I beg your pardon for the wall of text. If you know about color spaces just skip the "Theory" part.
In the following description I will only talk about RGB color spaces. For things like CMYK the same reasoning applies but I want to keep it simple. For the sake of readability. I will also simplify a terrible lot to keep this beginner friendly and easy to understand. Like, seriously simplify. No need to point that out. I am also aware that some of the limitations might be coming from the SVG specs or are at least implied in there (like the mandatory blending in gamma corrected or linear sRGB).
Theory
When we talk about (RGB, see above) colors we often only mention three numbers representing the value for each of the red, green and blue channel. In general 0 means "nothing" and 255 (8 bit values) or 1.0 (float values) means "full power". I will use the float notation here since it's easier to calculate in the head. Thus, something like (1, 0, 0) means "the reddest red" and (1, 1, 1) is "white".
Now, there is a problem once you want to display such a color: What does "full power" or "the reddest red" actually mean? That's where color spaces come into play. They define a set of "primaries" that tell us what "red", "green" and "blue" actually mean. They are defined in absolute, real world means (most often in XYZ) that directly relate to specific wavelengths of light and precisely define a color that can be displayed. With that knowledge it's possible to say that (1, 0, 0) is not just some reddest red, but what it looks exactly like. Every other color inside the [0..1] range per channel can thus be defined, too. Some popular color spaces are sRGB and AdobeRGB in the RGB world. The CMYK world has things like "ISO Coated v2".
Of course there is more than just one color space and most have different primaries. The colors that can be described with a given set of primaries is called the "gamut" of a color space – not to be confused with the color space's "gamma"! We will ignore the latter.
Now that we know that the same triplet of numbers does mean something different in different color spaces we also understand that the numbers alone are meaningless without a color space. Since there is a terribly large number of images – both raster and vector – without any color profile information attached there is the common default of assuming sRGB.
When looking at articles about color spaces there are almost always images of a horse shoe formed colorful diagram with a triangle on top (like https://commons.wikimedia.org/wiki/File:CIE1931xy_gamut_comparison.sv g). The background horse shoe represents all possible colors a typical human can see while the corners of the triangle are just the aforementioned primaries. The area of the triangle covers the colors that the colorspace can display*. With the AdobeRGB triangle being bigger than the sRGB one (and completely covering it) we can easily see that AdobeRGB contains colors that are not expressible in sRGB.
Besides these well known and standardized color spaces used to define colors in images there are also device color spaces that describe what colors some physical appliance can display. For now we will concentrate on monitor profiles since they are also RGB but of course also printers with four or even more colors can be measured and their primaries be determined. See the SWOP CMYK gamut in the sample image for a typical result of that. Back in the days of CRTs there was that prototypical monitor that exactly covered the sRGB color space – it's where it originated from. Nowadays with LCD displays and all that diverging technologies there isn't one typical display profile any longer. It turns out that most laptops and consumer grade displays cover less than sRGB while some high end monitors reach AdobeRGB or even wider gamuts. Therefore it's important to have proper color management in place so that the (1, 0, 0) you put into an image looks the same everywhere and not like an orange on some screens and a fire truck on another.
Current state of Inkscape
I have to admit that it's a while since I looked at the relevant code so my memory might be missing some details, but I am quite sure that the general picture I'm going to paint is in the right ballpark.
When Inkscape displays "normal" colors they are untagged, 8 bit values. So it's just something of the form (255, 0, 255) for a nice magenta. According to the SVG specs (http://www.w3.org/TR/SVG/color.html) this is implicitly assumed to be sRGB. Using the CMS mode of the Fill&Stroke dialog the user can also specify the color space to be something else, for example AdobeRGB. While the value set in that mode gets propagated to the SVG as-is and be tagged with its color space, internally it will be converted to sRGB. When the user also specified a display profile the result of the renderer will in the end be transformed from sRGB (that's what all the colors Inkscape works with are) to the display profile.
Problems
While in theory this seems to be a sound way to deal with colors – transforming everything to sRGB as the internal working space – it poses a few problems in practice. First and foremost there is the usage of 8 bit values. It doesn't allow very fine steps between tonalities. And the bigger the color space's gamut gets the worse it becomes. That is especially true when doing blending in linear space and not gamma corrected (never mind that detail, it's not the important part here). Just look at the diagram again. The same number of steps (255 in case of 8 bit values) have to stretch a wider range of real world colors, so every intermediate step gets bigger. Another problem with 8 bit colors is that there is nothing below 0 and nothing above 255. At first that might not look like a problem, after all, (255, 0, 0) is the reddest red. There is nothing more red, so why think about numbers that are bigger? Well, because as we have seen earlier, it's only the reddest red in its own color space. When looked at it in any bigger color space it's just an average red, there are redder reds. Therefore the transformation of colors into sRGB will leave wrong results when anything that is not inside the sRGB gamut is being transformed to it and at the same time clipped to the 8 bit range. The result can't be mapped back to the original color any longer. Even when the display is able to cover all the AdobeRGB colors and the user specifies the colors in that color space the displayed results will map everything outside of the sRGB gamut to its inside (there are several way to do that clamping, you can just cut the values off, scale them nicely, ... but at the end of the day they are not what they used to be).
To show the results of this clamping have a look at https://launchpadlibrarian.net/206984719/canvas_cms.png. Every row contains the same color value (shown on the left) four times, just tagged with different color spaces. So the first row should show the reddest red in AdobeRGB, sRGB and Laptop (some color space SMALLER than sRGB). We will ignore the GRB column, it's just there to show that color management was actually turned on. We notice that the first two columns look the same though. The reason is the clamping Inkscape does. The reddest red of AdobeRGB (i.e., its red primary) is far outside of sRGB's gamut. So Inkscape clamps the color and moves it to the closest sRGB contains: the reddest red sRGB knows. The same happens for green and blue. Once that happened every further step won't distinguish between the colors that once were very different and no matter what display profile is set the result will look the same. Because it is. Now for the third column. The Laptop profile has a smaller gamut than sRGB so when converting its primaries to sRGB they can be represented in the 8 bit range and are shown correctly in the resulting image.
A better world
All of this isn't that great for anything that is supposed to have correct colors and not be limited to sRGB. That might be less of a concern for Web graphics, but once you think about printing (most CMYK profiles are not inside the sRGB gamut) or even just seeing your work on a good monitor you have a problem.
The first step would be to get rid of the 8 bit limitation. Not only would that allow for smoother gradients (remember that step size? With float they become virtually arbitrarily small!) but floats also allow to transform colors to a smaller gamut without clipping them since the values can be bigger than 1.0. Of course, all color math has to be checked if it would still work with values bigger than "full power" and there are cases where it will fail. Thus as a second step it would be helpful to either replace sRGB with something bigger for the internal working space (not exactly what the SVG specs allow :-() or maybe even keep all colors in their original color space and only do transformations where needed. Since there are even problems when doing some computations in a gamut that can express all colors but isn't the original one it might even be a good idea to let the user specify a color space of the whole document so that all colors that are not tagged are treated as that color space instead of sRGB, i.e., specify the working space (again, not what the SVG specs call for). For documents not mixing colors of different color spaces that might be the best solution – just take all colors as-is, handle them like Inkscape already does (with the exception that it should really really do it in float and not 8 bit) and in the end convert from the document working space to the display color space.
- Actually this is just the colors with maximum saturation, the set
of all colors isn't a triangle but skewed box in 3D space. In order to compare color spaces it's enough to look at this projection though.
Thanks for reading Tobias
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
El vie, 09-10-2015 a las 18:42 +0200, Tobias Ellinghaus escribió:
but floats also allow to transform colors to a smaller gamut without clipping them since the values can be bigger than 1.0. Of course, all color math has to be checked if it would still work with values bigger than "full power" and there are cases where it will fail.
Let me see if I got this straight (probably the simplified explanation left some things out), but you seem to be considering the values beyond 0,1 for the colorspace math. In a display-referred model (ICC is) colors beyond the 0,1 range are undefined, unless you have something like lcms' (and GEGL's) unbounded RGB. Encoding out-of-gamut values outside the 0,1 range could be fine for storage and conversions, but it might be very problematic for editing, specially for arithmetic RGB operations like multiplication since you can end up with negative RGB values and shifted channels.
It seems safer to stick with the good-old "destructive" colorspace transforms (i.e. wider gamut is mapped to smaller gamuts and the out-of -gamut values are lost). Otherwise even simple RGB compositing could fall apart.
Artists should choose their desired colorspace as one of the first decisions, then deal with that choice (For instance: if you chose wide gamut and you're targetting for the web, you'll likely lose gamut. You should know that).
Apart from that, higher bit depth and floats could allow high dynamic range scene-referred imaging (where RGB data goes from 0 to infinity and values beyond 1 aren't used for encoding out of gamut colors but light intensity). Using those values for storing out-of-gamut color would be probably incompatible. It's probably way out of the scope of SVG and a vector drawing program to think about HDR, but the trend in digital imaging seems to be going towards linear RGB compositing and HDR anyway.
Gez.
On Sat, 2015-10-10 at 02:00 -0300, Gez wrote:
It's probably way out of the scope of SVG and a vector drawing program to think about HDR, but the trend in digital imaging seems to be going towards linear RGB compositing and HDR anyway.
That would be this:
https://en.wikipedia.org/wiki/High-dynamic-range_imaging
Not this:
https://en.wikipedia.org/wiki/RGBE_image_format
right?
Martin Owens
El sáb, 10-10-2015 a las 01:25 -0400, Martin Owens escribió:
On Sat, 2015-10-10 at 02:00 -0300, Gez wrote:
It's probably way out of the scope of SVG and a vector drawing program to think about HDR, but the trend in digital imaging seems to be going towards linear RGB compositing and HDR anyway.
That would be this:
https://en.wikipedia.org/wiki/High-dynamic-range_imaging
Not this:
https://en.wikipedia.org/wiki/RGBE_image_format
right?
Yes, but RGBE is not completely unrelated as it's a format for storing HDR images. EXR is another format for that, widely used in VFX and high -end imaging.
It's worth to mention that HDR doesn't mean tone-mapped HDR. It's a common misconception: a tone-mapped HDR image is not HDR anymore. I'd also add that although photography and photo-real VFX and CG are the most common applications of HDR images, it doesn't stop there.
This is Krita painting in HDR, for instance. https://www.youtube.com/watch?v=esSzKzXVWQE https://www.youtube.com/watch?v=o7AF302wdrM
G.
Quick question from a simple user
"Using the CMS mode of the Fill&Stroke dialog......"
Is the CMS mode only available in the dev versions? Or does it not appear for me because I don't have a color profile?
Just trying to understand a very little bit :-)
brynn
-------------------------------------------------- From: "Tobias Ellinghaus" <houz@...173...> Sent: Friday, October 09, 2015 10:42 AM To: inkscape-devel@lists.sourceforge.net Subject: [Inkscape-devel] A discussion about color management in Inkscape
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
El sáb, 10-10-2015 a las 10:36 -0600, Brynn escribió:
Quick question from a simple user
"Using the CMS mode of the Fill&Stroke dialog......"
Is the CMS mode only available in the dev versions? Or does it not appear for me because I don't have a color profile?
Just trying to understand a very little bit :-)
The CMS tab is the last tab in the fill and stroke solid colors (check the buttons that let you choose RGB, HSL, CMYK, colorwheel and... CMS).
It's available in 0.91 and it was available in 0.48 as well.
However, it won't be immediately usable unless you link a profile via de document properties. The behavior for RGB profiles is a bit awkward, it's easier to see how it works with a CMYK profile.
Gez.
El sáb, 10-10-2015 a las 02:00 -0300, Gez escribió:
It seems safer to stick with the good-old "destructive" colorspace transforms (i.e. wider gamut is mapped to smaller gamuts and the out -of -gamut values are lost). Otherwise even simple RGB compositing could fall apart.
Some further thoughts about this subject: Maybe it is possible to retain wider gamut to a certain extent if the color swatches store color in a device-independent colorspace and they get converted (destructively) to the working RGB/CMYK space for manipulation. I mean, if your colours are defined in, say CIE Lab, and you choose sRGB as your RGB working space, all the compositing math can be done without dealing with color management after colors are converted to sRGB. Now, if you change your mind and change the RGB colorspace of the documents, colors could be remapped from the original device -independent space to your new target space, instead of converting from your previous RGB space to the new one. This could work for linked images too (working with a cached copy of the original image converted to the chosen colorspace) but it would be trickier for embedded images. Of course, both images and swatches should be tagged with its source colorspace to allow conversions.
That can be done with display-referred values without having to recour to out-of-gamut values stored in the RGB channels and its potential complications.
However, I'm not sure if this is compatible with SVG and it's probably a problem with Cairo.
Gez.
Ooh, I see. I thought it was the grayed out button near the bottom of the dialog.
Thanks :-)
-------------------------------------------------- From: "Gez" <listas@...3059...> Sent: Saturday, October 10, 2015 4:01 PM To: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] A discussion about color management in Inkscape
El sáb, 10-10-2015 a las 10:36 -0600, Brynn escribió:
Quick question from a simple user
"Using the CMS mode of the Fill&Stroke dialog......"
Is the CMS mode only available in the dev versions? Or does it not appear for me because I don't have a color profile?
Just trying to understand a very little bit :-)
The CMS tab is the last tab in the fill and stroke solid colors (check the buttons that let you choose RGB, HSL, CMYK, colorwheel and... CMS).
It's available in 0.91 and it was available in 0.48 as well.
However, it won't be immediately usable unless you link a profile via de document properties. The behavior for RGB profiles is a bit awkward, it's easier to see how it works with a CMYK profile.
Gez.
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (6)
-
Brynn -
Gez -
Jabiertxo Arraiza Cenoz -
Martin Owens -
Nathan Hurst -
Tobias Ellinghaus