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

El 2014-04-22 15:25, yahvuu escribió:

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]