Re: [Gimp-developer] Soft proofing and the GIMP Display Filters and Color Management settings

On 03/13/2014 04:05 AM, Gez wrote:

El mié, 12-03-2014 a las 02:19 -0400, Liam R E Quin escribió:
On Tue, 2014-03-11 at 15:45 -0300, Gez wrote:
::snip? SNIP!::
 From a user point of view having all the imported stuff converted
automatically to a high quality internal model (high bit depth linear
scRGB?) and having per-image output/proof settings seems more
straightforward and less error prone than the current mixture of

Are you going to pay for the extra memory I'll need? I only have 32G and
already with 2.9 I sometimes am swapping.

No, but I can make you some coffee while you wait :-p

Ok, good point. I missed the segment of users who work with huge scans
On the other hand, is 8-bit enough for the type of work you do? Although
I'm still using 8 bpc for my work because I do it with GIMP 2.8, I have
a really hard time trying to keep good quality after a few rounds of
Maybe defaulting to 32bpc is too resource-intensive for a lot of works,
but wouldn't make more sense to have a higher quality default for
editing and keeping 8 bpc just as an output bit depth?

Anyway, rather than bitdepth, my comment was about giving the artists a
framework to create freely without worrying (much) about the constraints
of input/output colorspaces.
It's impossible to have that with 8 bpc. And correct me if I'm wrong,
but I suspect that using proofing filters on non-linear 8bpc carries a
lot of problems and the result can't be completely reliable.

Maybe we can have the flexibility and power just keeping two modes: 16
bit integer for memory-conservative tasks and 32 bit float for high
quality stuff.
Economy of system resources is important, but I'm sure that image
quality is far more important in a image manipulation program.

It depends, right? I'm a photographer. Let's suppose I've got a D800 and a digital medium format body. The D800 is 36MP and captures 10 or 12bpc; the MF is 50MP and captures 14bpc.

On day one, I shoot a breaking-news assignment for a print newspaper or a wire service. In that case, my priority is speed first, quality second, because newsprint only barely qualifies as paper, and wire photos tend to be low-resolution anyway.

While I'm churning through images on my laptop, converting _to_ a high-bit-depth representation and then _from_ that representation back to 8-bit sRGB is both a waste of time and a waste of battery power. That's time I could have spent researching captions, or talking to people, or just getting back out and back to shooting.

A week later, I shoot a piece for a magazine with a 50MP digital medium-format camera. The assignment is set to run a month later, and I'm working on it on my home machine with a ton of memory. In that case, quality is of the essence, and if it takes a few minutes to (say) run sharpening, that's annoying, but it's not all that big of an issue.

By virtue of shooting MF, I care about my gradients more than pretty much anything else, and so I immediately convert from the 14bpc input (encoded as 16bpc files) to 32bpc to avoid introducing any aliasing during post-processing.

The point of this example is that while it makes sense to choose sensible defaults, and to make efforts to keep the user from shooting herself in the foot, I don't think it makes sense to prevent the user from taking direct control of those settings if she so chooses.

It may or may not be a problem for keeping legacy compatibility, but I
can imagine how simplified the UI and common workflows would be (no
bit-depth "modes", no assign/convert to profile, no profile-mismatch
warnings, simplified CM preferences, etc).

You might not always be able to do round-tripping, because a colour in
the input image's colour model might be out of gamut for the working
profile. I don't know how big an issue that would be. Similarly you'd
end up using colours that wouldn't come out at all right on your output
device. The warnings are there for a reason...

scRGB exceeds the gamut of the usual profiles, following what I proposed
in the previous message, if you go -for instance- AdobeRGB -> scRGB ->
AdobeRGB with enough precision that shouldn't be a problem and RGB <->
CMYK roundrip is impossible anyway.

As I tried to demonstrate, requiring the user to convert to different color profiles may be problematic. But using a wide gamut color space at low bit depth is also problematic. In the example, photojournalist-me simply wants to work in 8-bit sRGB. All of the stuff that actually required high bit depth (bringing up really low shadows and whatnot) is stuff I'd have already done in the RAW converter, before that image data even got to GIMP.

I'm not an expert by any means and I might be wrong, but that doesn't
seem to contradict what I said.
And regarding "you'd end up using colours that wouldn't come out at all
right on your output device", that's exactly what soft-proofing (the
topic of this thread) would prevent.
If you have in the workflow I presented, say an AdobeRGB image as input,
it would be converted to scRGB. All its colours would fall inside the
scRGB gamut, so no problem. If you save back to AdobeRGB without
changing anything, color shouldn't change.
If you save to sRGB, colors would have to be converted using a rendering
intent, because the output gamut is smaller. You could soft-proof your
editing against sRGB to see how colors would be affected with the
selected rendering intent.
The good thing about this is that your XCF file would store unmodified
color information, and that would allow to save later to AdobeRGB,
Prophoto or whatever you want.
Now, if you were obligated to convert your imported image to a working
profile (like you are now), and that profile has a smaller gamut than
the original image, your imported image is hopelessly degraded. You're
always tied to the color gamut of your working RGB profile.

You are not currently obliged to convert imported images to a working profile. "File Open Behaviour" has three settings, and one is "Keep embedded profile."


Anyway, this is just an idea. It's not a small change and I'm not
suggesting that it has to be done the way I said. I think this is an
interesting topic to discuss since seems more suitable for
non-destructive editing than the current approach.


gimp-developer-list mailing list
List address:    gimp-developer-list gnome org
List membership:
List archives:

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