Re: [Gimp-developer] Histograms in unbounded mode sRGB
On 04/24/2014 09:38 AM, Alexandre Prokoudine wrote: On Thu, Apr 24, 2014 at 1:28 PM, Omari Stephens wrote: How am I supposed to use these colors to make a logo without entering numbers? What you are really asking is how you should use Pantone colors in GIMP, aren't you? Pantone colors would be awesome, but I figure it's probably not feasible for legal reasons. OMG. People still actually believe this long debunked myth? :) Don't let my misconceptions stop someone from making Pantone easy to use from GIMP :o) --xsdg Even so, Pantone doesn't cover every situation, and there will be plenty of GIMP users who have never heard of Pantone before, or don't have a book, or whatever other reason. Where I live companies either have a brandbook with Pantone/CMYK/HSV colors defined to use on the web and in print, or expect you to use sRGB triple indeed. Alexandre ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Histograms in unbounded mode sRGB
On Thu, Apr 24, 2014 at 1:28 PM, Omari Stephens wrote: >>> How am I supposed to use these colors to make a logo without entering >>> numbers? >> >> >> What you are really asking is how you should use Pantone colors in >> GIMP, aren't you? > > > Pantone colors would be awesome, but I figure it's probably not feasible for > legal reasons. OMG. People still actually believe this long debunked myth? :) > Even so, Pantone doesn't cover every situation, and there > will be plenty of GIMP users who have never heard of Pantone before, or > don't have a book, or whatever other reason. Where I live companies either have a brandbook with Pantone/CMYK/HSV colors defined to use on the web and in print, or expect you to use sRGB triple indeed. Alexandre ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Histograms in unbounded mode sRGB
On 04/24/2014 09:14 AM, Alexandre Prokoudine wrote: On Thu, Apr 24, 2014 at 12:01 PM, Omari Stephens wrote: Here's a simple situation where numbers matter: Suppose I'm a designer. My client wants a new logo. They give me a list of colors that match their branding. How am I supposed to use these colors to make a logo without entering numbers? What you are really asking is how you should use Pantone colors in GIMP, aren't you? Pantone colors would be awesome, but I figure it's probably not feasible for legal reasons. Even so, Pantone doesn't cover every situation, and there will be plenty of GIMP users who have never heard of Pantone before, or don't have a book, or whatever other reason. Those users still need to be able to collaborate, and the least common denominator is generally still an sRGB triple. Moreover, if someone says "make an image that works with the colors on my website," you can't use Pantone with CSS. Again, the least common denominator is an sRGB triple. --xsdg ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Histograms in unbounded mode sRGB
On Thu, Apr 24, 2014 at 12:01 PM, Omari Stephens wrote: > Here's a simple situation where numbers matter: > > Suppose I'm a designer. My client wants a new logo. They give me a list of > colors that match their branding. > > How am I supposed to use these colors to make a logo without entering > numbers? What you are really asking is how you should use Pantone colors in GIMP, aren't you? Alexandre ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Histograms in unbounded mode sRGB
Here's a simple situation where numbers matter: Suppose I'm a designer. My client wants a new logo. They give me a list of colors that match their branding. How am I supposed to use these colors to make a logo without entering numbers? Or suppose I need to create signage that contains, by government decree, an official color such as Safety Orange*. I don't want to jump through hoops. What I want to do is choose the foreground color, go into the color picker, type in sRGB(232, 118, 0) or HSV(31°, 100%, 91%) and get rolling. It is correct that there's no guarantee that by doing this, the color that comes out of the printer will actually be Safety Orange, but that latter problem is an issue of soft proofing, as Elle had already mentioned. Assuming an accurate soft-proof setup, then I first enable soft-proofing, then go into the color picker and tell it that I want sRGB (232, 118, 0). At that point, it should (but I'm pretty sure it doesn't currently :o) convert that to the actual color value that will produce Safety Orange when the sheet comes out of the printer. * http://en.wikipedia.org/wiki/Safety_orange --xsdg On 04/22/2014 06:25 PM, yahvuu wrote: Hi, Am 18.04.2014 22:10, schrieb Elle Stone: I think the only reasonable solution is to keep the WideGamutRGB chromaticities available for use as an editing/compositing color space, and use that color space to display histogram information (and also to display Color Picker and Color Selector information). please allow me to make the case for using the color space of the respective export file format for histogram displays. You recently gave striking examples of how working with RGB _numbers_ can quickly become unwieldy from a user point of view. This probably applies as soon as the limitations of the traditional 8-bit sRGB processing are relaxed. There is nothing wrong with RGB color models, it is just that the numbers can become difficult to interpret for human beings. So, as a thought experiment, i'd like to get rid of any kind of RGB triples in the UI. To see where it hurts the most. This will be the places where RGB numbers are really needed. After all, GIMP is about colors, not numbers. Say, we get an adobeRGB camera image and the task is some touch-up and warping. The deliverables are 1) a JPG for the web and 2) a proPhotoRGB file for that mega stock company. I find that most of the editing can be performed without looking at a single RGB triple. Image transforms do not expose RGB numbers, neither do most of the filters. Even many of the tools in the Colors menu do not refer to RGB numbers. Of course, this is different for levels/curves. But by large, these tools are used on the 'value' channel, not on the distinct R,G,B channels. Here, working on the luminance channel instead would probably be an improvement. I find it is only on *export* when the RGB numbers become really important. Much like output-specific scaling and sharpening, each of the deliverables needs specific color treatment. Here, the histograms need to show the R,G,B channels of the specific output color space to allow assessment and correction of the conversion. Probably, this is also where the curves/levels tools should be working in the output color space. For example, how else could someone boost the midtones without adding clipping -- when maximum and minimum range of the curve do not refer to the actual range of the output file format? (not even talking of non-matching color primaries here) These color modifications that are specific to the output files are hot candidates for being stored in export pipelines, again analogous to scaling and sharpening operations. I'm less sure in how far this is an analogy to CMYK export -- is an equivalent to the 'press projection' needed here? Or is it sufficient to set the RGB color space of histogram/curves etc. to the currently active softproofing color space? best regards, yahvuu ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Histograms in unbounded mode sRGB
On 04/22/2014 02:25 PM, yahvuu wrote: Hi, Am 18.04.2014 22:10, schrieb Elle Stone: I think the only reasonable solution is to keep the WideGamutRGB chromaticities available for use as an editing/compositing color space, and use that color space to display histogram information (and also to display Color Picker and Color Selector information). please allow me to make the case for using the color space of the respective export file format for histogram displays. You recently gave striking examples of how working with RGB _numbers_ can quickly become unwieldy from a user point of view. This probably applies as soon as the limitations of the traditional 8-bit sRGB processing are relaxed. There is nothing wrong with RGB color models, it is just that the numbers can become difficult to interpret for human beings. So, as a thought experiment, i'd like to get rid of any kind of RGB triples in the UI. To see where it hurts the most. This will be the places where RGB numbers are really needed. After all, GIMP is about colors, not numbers. Say, we get an adobeRGB camera image and the task is some touch-up and warping. The deliverables are 1) a JPG for the web and 2) a proPhotoRGB file for that mega stock company. I find that most of the editing can be performed without looking at a single RGB triple. Image transforms do not expose RGB numbers, neither do most of the filters. Even many of the tools in the Colors menu do not refer to RGB numbers. Of course, this is different for levels/curves. But by large, these tools are used on the 'value' channel, not on the distinct R,G,B channels. Here, working on the luminance channel instead would probably be an improvement. I find it is only on *export* when the RGB numbers become really important. Much like output-specific scaling and sharpening, each of the deliverables needs specific color treatment. Here, the histograms need to show the R,G,B channels of the specific output color space to allow assessment and correction of the conversion. Probably, this is also where the curves/levels tools should be working in the output color space. For example, how else could someone boost the midtones without adding clipping -- when maximum and minimum range of the curve do not refer to the actual range of the output file format? (not even talking of non-matching color primaries here) These color modifications that are specific to the output files are hot candidates for being stored in export pipelines, again analogous to scaling and sharpening operations. I'm less sure in how far this is an analogy to CMYK export -- is an equivalent to the 'press projection' needed here? Or is it sufficient to set the RGB color space of histogram/curves etc. to the currently active softproofing color space? best regards, yahvuu You make excellent points about the need for better soft proofing tools, including access to channel information, histograms, and sample point data in the output color space. On the one hand, I think you are right to assume that many people likely never look at sample points, histograms, channel data, and RGB values while editing. So for this group of people the colors they see on the screen is all that matters. On the other hand, many people edit "by the numbers". Perhaps not as many people edit by the numbers as by sight only. But surely a large percentage of the high end users who are in the GIMP target audience do edit by the numbers as well as visually. I use sample points, histograms, channel data, and the color picker and color selector constantly while editing, for example: * To make sure I don't drive channel data out of gamut of the color space that I wish I were editing in. * To calculate what color blending layer I might want to use to correct a color balance problem or to change the color balance in a particular way. * To verify that a spot that should be neutral, really is neutral, and to correct the RGB invidual channel intensities if it isn't neutral. * To see how much headroom an image might have. * To check the "zones" distribution (it's awfully easy to get carried away adding contrast to an image). * As a check on inadvertently introduced hue changes. Seeing RGB values like 1.6 or -0.02 makes it literally impossible to use sample points, histograms, channel information and the color picker and color selector in the usual "by the numbers" type of fashion, because I don't intuitively know things like: * What are the equivalent RGB values make reddest red for the color space that I really want to work in? * How far negative can the blue or green channel go before it's out of gamut with respect to the color space that I really want to work in? * How far positive can the red or green channel go before it's out of gamut with respect to the color space that I really want to work in? When working in one's color space of choice, these crucial bits of numberical information are taken for granted, le
Re: [Gimp-developer] Histograms in unbounded mode sRGB
El 2014-04-22 15:25, yahvuu escribió: Hi, Am 18.04.2014 22:10, schrieb Elle Stone: I think the only reasonable solution is to keep the WideGamutRGB chromaticities available for use as an editing/compositing color space, and use that color space to display histogram information (and also to display Color Picker and Color Selector information). please allow me to make the case for using the color space of the respective export file format for histogram displays. You recently gave striking examples of how working with RGB _numbers_ can quickly become unwieldy from a user point of view. This probably applies as soon as the limitations of the traditional 8-bit sRGB processing are relaxed. There is nothing wrong with RGB color models, it is just that the numbers can become difficult to interpret for human beings. So, as a thought experiment, i'd like to get rid of any kind of RGB triples in the UI. To see where it hurts the most. This will be the places where RGB numbers are really needed. After all, GIMP is about colors, not numbers. Say, we get an adobeRGB camera image and the task is some touch-up and warping. The deliverables are 1) a JPG for the web and 2) a proPhotoRGB file for that mega stock company. I find that most of the editing can be performed without looking at a single RGB triple. Image transforms do not expose RGB numbers, neither do most of the filters. Even many of the tools in the Colors menu do not refer to RGB numbers. Of course, this is different for levels/curves. But by large, these tools are used on the 'value' channel, not on the distinct R,G,B channels. Here, working on the luminance channel instead would probably be an improvement. I find it is only on *export* when the RGB numbers become really important. Much like output-specific scaling and sharpening, each of the deliverables needs specific color treatment. Here, the histograms need to show the R,G,B channels of the specific output color space to allow assessment and correction of the conversion. Probably, this is also where the curves/levels tools should be working in the output color space. For example, how else could someone boost the midtones without adding clipping -- when maximum and minimum range of the curve do not refer to the actual range of the output file format? (not even talking of non-matching color primaries here) These color modifications that are specific to the output files are hot candidates for being stored in export pipelines, again analogous to scaling and sharpening operations. I'm less sure in how far this is an analogy to CMYK export -- is an equivalent to the 'press projection' needed here? Or is it sufficient to set the RGB color space of histogram/curves etc. to the currently active softproofing color space? This is no doubt an interesting thought experiment, but I'm afraid it can't live much beyond it. The way users interact with GIMP is too complex to do something like that. Your example cherry-picks situations where the color part can be left for the final stage, but there are several manipulations where you start by doing some color correction. And since RGB is how digital color images are stored, having tools for watching what's going on in channels while you edit (like histograms, waveforms, etc.) is essential for manipulating color with accuracy. Destroying image data inadvertently is easier than you think, specially when you're manipulating data that doesn't fit in your output device's gamut. And all this things start to sound like squaring the circle. Again, it's an interesting thought experiment, but if we need thought experiments to make a model fit, breaking the existing paradigms of image manipulation, then there's probably something wrong with the model. I'm not against different ways of doing things, but it seems like making the unbounded RGB model fit requires to re-think a lot of the existing structure, not only the internals of GIMP but also how users use the tool. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Histograms in unbounded mode sRGB
Hi, Am 18.04.2014 22:10, schrieb Elle Stone: > I think the only reasonable solution is to keep the WideGamutRGB > chromaticities available for use as an editing/compositing color space, > and use that color space to display histogram information (and also to > display Color Picker and Color Selector information). please allow me to make the case for using the color space of the respective export file format for histogram displays. You recently gave striking examples of how working with RGB _numbers_ can quickly become unwieldy from a user point of view. This probably applies as soon as the limitations of the traditional 8-bit sRGB processing are relaxed. There is nothing wrong with RGB color models, it is just that the numbers can become difficult to interpret for human beings. So, as a thought experiment, i'd like to get rid of any kind of RGB triples in the UI. To see where it hurts the most. This will be the places where RGB numbers are really needed. After all, GIMP is about colors, not numbers. Say, we get an adobeRGB camera image and the task is some touch-up and warping. The deliverables are 1) a JPG for the web and 2) a proPhotoRGB file for that mega stock company. I find that most of the editing can be performed without looking at a single RGB triple. Image transforms do not expose RGB numbers, neither do most of the filters. Even many of the tools in the Colors menu do not refer to RGB numbers. Of course, this is different for levels/curves. But by large, these tools are used on the 'value' channel, not on the distinct R,G,B channels. Here, working on the luminance channel instead would probably be an improvement. I find it is only on *export* when the RGB numbers become really important. Much like output-specific scaling and sharpening, each of the deliverables needs specific color treatment. Here, the histograms need to show the R,G,B channels of the specific output color space to allow assessment and correction of the conversion. Probably, this is also where the curves/levels tools should be working in the output color space. For example, how else could someone boost the midtones without adding clipping -- when maximum and minimum range of the curve do not refer to the actual range of the output file format? (not even talking of non-matching color primaries here) These color modifications that are specific to the output files are hot candidates for being stored in export pipelines, again analogous to scaling and sharpening operations. I'm less sure in how far this is an analogy to CMYK export -- is an equivalent to the 'press projection' needed here? Or is it sufficient to set the RGB color space of histogram/curves etc. to the currently active softproofing color space? best regards, yahvuu ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Histograms in unbounded mode sRGB
On 04/18/2014 04:10 PM, Elle Stone wrote: If a user opens, for example, a ProPhotoRGB image, I think it is unrealistic to expect that the user will understand what values like -13.37 and + 1.36 mean in the image histogram (or what these values mean in the Color Picker or Color Selector). I think the only reasonable solution is to keep the WideGamutRGB chromaticities available for use as an editing/compositing color space, and use that color space to display histogram information (and also to display Color Picker and Color Selector information). Drat those typos. I meant keep the ProPhotoRGB chromaticities available. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
[Gimp-developer] Histograms in unbounded mode sRGB
A long while back the topic came up on IRC about how to deal with histograms when an image has been converted from a wider gamut color space to unbounded mode sRGB. I tried to come up with a possible solution and failed. I do have some sample data. You can download a test image from here: http://ninedegreesbelow.com/gimpgit/gimp-srgb/color-blocks-in-regular-srgb.xcf The test image is a series of six color blocks in each of five different color spaces, all converted to the unbounded mode regular sRGB color space at 32-bit floating point. The color blocks are labelled so you can tell which set of blocks is which. The image has the most saturated possible red, green, yellow, blue, and magenta colors for the sRGB, Adobe RGB (1998), Rec. 2020, WideGamutRGB, and ProPhotoRGB color spaces. These most saturated colors represent more or less outer boundaries of the possible range of colors found in LDR images. There are more intense real greens and cyans than are included in the color blocks. ProPhotoRGB's greenest green and bluest blue are actually imaginary rather than real colors. To provide an idea of the range of RGB values after converting to unbounded mode sRGB: In the unbounded mode regular sRGB color space: ProPhotoRGB cyan is -13.37 in the red channel. WideGamutRGB magenta is -3.77 in the green channel. ProPhotoRGB yellow is -2.09 in the blue channel. ProPhotoRGB red is +1.36 in the red channel. WideGamutRGB green is +1.12 in the green channel. WideGamutRGB blue is +1.09 in the blue channel. In the unbounded mode linear gamma sRGB color space: ProPhotoRGB red is +2.03 in the red channel. WideGamutRGB green is +1.29 in the green channel. WideGamutRGB blue is +1.16 in the blue channel. If a user opens, for example, a ProPhotoRGB image, I think it is unrealistic to expect that the user will understand what values like -13.37 and + 1.36 mean in the image histogram (or what these values mean in the Color Picker or Color Selector). I think the only reasonable solution is to keep the WideGamutRGB chromaticities available for use as an editing/compositing color space, and use that color space to display histogram information (and also to display Color Picker and Color Selector information). Dynamically normalizing the information to "just fit" all the RGB values between 0.0 and 1.0 in the histogram display means that, for example: Before any editing is done, the histogram range will have a maximum value of 1.0. If the user adds saturation, some RGB values will increase, and the normalized range will dynamically expand to still have a maximum value of 1.0. And if the user lowers saturation in an image, some RGB values will decrease and the range of RGB values will dynamically contract to still have a maximum value of 1.0. Thus the "information" aspect of the histogram would be severely comprised. In fact normalizing the histogram RGB values would make the histogram useless. It would convey shape and relative intensity as expressed in the unbounded sRGB color space (very different from the corresponding information in the source color space) with no indication of absolute intensity of color. So it seems logical and also much more user-friendly to always construct the image histogram information in a compositing/editing color space based on the source color space chromaticities. Similar considerations would apply to histograms that are displayed in the Levels and Curves dialogs. Elle ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
