Re: [Gimp-developer] Histograms in unbounded mode sRGB

[Omari Stephens <xsdg xsdg org>]

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