Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL

First, in spite of the intensity of this discussion, I appreciate it.
Thanks to all contributors for your efforts to make it clear.

A simple question, which may have been answered already and I may have
missed (if so, a pointer will do).  

What is the advantage of using unbounded sRGB instead of user RGB, 
*presuming* user RGB is not sRGB, and ignoring assumptions any outside
software may be making about colorspace?

I'm having a great deal of difficulty understanding why one would choose 
to use a pipeline which by definition is going to require conversions 
when the user is using anything except sRGB.  Both from a potential loss /
distortion of data perspective and from a simple performance perspective. 

As people become more comfortable with different colorspaces, and as they 
become more comfortable dealing with individual color channels, more and 
more work will be done using them.  Particularly as device prices keep 
coming down and capabilities going up.

I can understand how / why one might wish to work in unbounded sRGB as
an interim step towards a goal of working in user RGB *if* doing so 
gets significant results considerably faster than would otherwise be
possible; and if doing so does not result in a lot of effort which will 
be discarded at the next step.  But I have difficulty understanding why 
it would be the final design goal.  The final design goal should be to
get it right.  If one were starting from scratch, would one choose to
use unbounded sRGB?

I've personally made this mistake once and it resulted in the death of
a good product.  I also worked for a company which made this mistake
and it cost them a year of (re)development when technology caught up with 
their assumptions.


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