Re: [Gimp-developer] GIMP's future internal image data format

["gespertino gmail com" <gespertino gmail com>]

2012/1/31 Bogdan Szczurek <thebodzio gmail com>

I agree that having more precision is more favourable mathematically. But is it so "visually"? I mean we'd have more precisely determined color components but will it really "show"? And if it will, then how much? Just a couple of questions, that, I believe, can't be answered right now. I said it before, I say it again: let's wait and see :). Real world application will for sure provide us with "proofs", while continuing this could unfold into battle of "I thinks" and "IMHOs" not "knows".

The case of 8 bit being insufficient and the rounding errors caused by working with such low precision is more common that one would think.
I used to think that it wasn't so critical, but after a couple of simple tests you might change your mind.
- Gradients. Go from 30% gray to white. Dithering will make it more pleasing visually, but adjust contrast and you'll see immediately you're short of shades to work with.
- Create a black shape on white background. Apply 50 px gaussian blur. Ajdust curves and you'll see banding immediately.
- Painting with soft edge brushes. Banding appears almost instantly when you make a couple of overlapped strokes.
 
Grayscale with reduced dynamic range is almost impossible to work with using 8bpc and the destructive effects will show even with slight adjustments.
I use to design some brochures for a company that sales cars, and everytime I have to touch up an image of a car (mostly in silver colors) I have to duplicate, blur and diher patches to avoid banding. And I don't do extreme manipulations there.
Another example is banding in skies in landscape photos.

Here I have to quote my friend Troy Sobotka who's usually a jerk towards GIMP :-p but makes a point:
http://troy-sobotka.blogspot.com/2011/01/bit-depth-and-confusion.html

I'm not worried about the excess of data. That overhead is useful and will be discarded anyway if you save to a 8bpc format, so I don't see the problem there.
I just wonder if performance won't be substancially degraded when such amount of data is handled.
AFAIK other applications as Photoshop or Mypaint are using 15bpc for working with 8bpc images, leaving higher precision (photoshop) for higher bitdepth "modes".
I'm sure devs are considering this problem, but my concern is what will happen with gimp right after GEGL is fully integrated and before it gets optimizations to make its performance really usable.
What's the plan? Realeasing GIMP with high bit depth when it's ready or hold the realease until its fast enough?

A focal point is needed and if it had to be RGB… well… so be it. Meantime why not to think a little bit about the future? :) Why not dwell for moment in a world of non-square pixels, generic substractive and additive color models (who said RGB is *the best* and *ultimate* solution?), non-orthogonal pixel grids… dreams, dreams… :) That's it for the (hopefully) "inceptive" off-topic :)

We had this conversation before, and I keep my stand about CMYK. If we can have a CMYK "projection" like Pippin and Peter suggested some time ago, and if we have control over layers to make them "project" directly to pure CMYK primaries or spot channels, then we can have a good CMYK/spot workflow without having to deal with "modes"

For example: Imagine you can fill an RGBA layer with cyan and you can "tag" that layer to tell gimp it will only separate to cyan in the CMYK projection. That would address the need of spot channels (and CMYK primaries, which are used as spot channels as soon as you decide to define them manually).

The other situation to solve to get proper CMYK would be controlling the black generation and that's it.
Color managed conversion from RGB to CMYK with control of the primaries is all that you need to get proper CMYK, and that wouldn't require a special "mode".