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

[Omari Stephens <xsdg xsdg org>]

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
> > > profiles.
> >
> > 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
> completely.
> 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
> edits.
> 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."

--xsdg

> 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.
>
> Gez.
>
> _______________________________________________
> 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