Re: Soft proofing and the GIMP Display Filters and Color Management settings

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

 



El jue, 13-03-2014 a las 06:43 +0000, Omari Stephens escribió:

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

I won't say you're wrong because this is matter of preferences, but I
don't think it's a good idea to sacrifice quality because the output is
limited.
That should be in the realm of export, not of processing. I think it's
always better to keep quality as high as possible in your project files
and degrade it (to lower bitdepth, smaller gamut, etc.) only when
exporting the deliverable file.
Why? Because you never know if you'll need the image for a different
output. 
What if adjust a photo for the resolution and quality of newsprint, and
that photo wins a prize or something and they ask you a better quality
picture for a magazine or a large format print?
For the same reason you don't (or your shouldn't) work with small jpgs
over-compressed, only because "it's just for the web".

The early binding print workflow presents the same problem: If you
convert your image to a small gamut colorspace you're restricting the
use of that image to that specifica output. Not the best idea in a world
where images are likely to be published in different media.

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

Well,I think it depends on the penalty of such operation.
It's a technical issue and since I'm not a developer I can't predict how
much impact something like that will have.
I know it's not impossible. Several high end image compositing and raw
development packages use that approach.


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

What I'm proposing doesn't necessarily take control from users.
If it can be done with a reasonable performance and use of system
resources users wouldn't see much difference, only a simplified and less
workflow.


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

Sure, that's why I suggested high bit depth. Maybe always 32bpc float is
too much, but what about 16 bit integer for that kind of works? 

Wouldn't it be a reasonable compromise for the lower-end of processing?
It would eat extra resources, but it would mitigate most of the huge
downsides of 8bpc.

If you already used a RAW converter (that is likely to work
non-destructively in high bit depth), why not saving your image in
16-bit for the final touches in the image manipulation program?
You would be able to export the final result to 8-bit sRGB.

What I'm trying to discuss here is the real need of keeping such a
destructive low end and a inefficient legacy color management workflow.

What's the impact of moving from 8bpc integer to 16bpc integer in terms
of memory consumption and performance? Is it a reasonable compromise
considering the important gain in quality and precision?

(these are honest questions. I'd love to know what developers think
about it).

I just opened a 12 megapixels image in GIMP 2.9, I did some operations
on it both in 8 bpc integer and 16 bpc integer.
The difference in performance was almost unnoticeable, and for a single
layer the difference in memory consumption was around 300 megabytes.
Of course, adding layers adds up, but if the argument was to perform
some quick edits on an underpowered laptop and quality doesn't matter
much, a complex multilayer composite is out of the question. 

> 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."

You're right. But have you considered the consequences of editing an
image in a large-gamut colorspace in 8-bit integer?
AdobeRGB isn't enormous, and posterization will show up earlier than in
sRGB.
Of course you won't notice it if you're doing minor tweaks, but do you
think it's worth to keep 8-bit and editing in the source colorspace just
because it would take some extra CPU cycles to take it to a larger gamut
working space?

Thanks for your feedback. I'm not trying to prove who's wrong or right
here, just trying to discuss the validity of assumptions we make (mine
included, of course).

Gez.

_______________________________________________
gimp-developer-list mailing list
List address:    gimp-developer-list@xxxxxxxxx
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list





[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux