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

[Bogdan Szczurek <thebodzio gmail com>]

W dniu 12-01-28 20:47, Øyvind Kolås pisze:
> On Sat, Jan 28, 2012 at 7:23 PM, Bogdan Szczurek<thebodzio gmail com> 
 wrote:
>> W dniu 12-01-28 15:37, Øyvind Kolås pisze:
>> I've mentioned it in other post, but for the sake of convenience 
I'll repeat
>> it here.
>>
>> "Color model" is not just about having this or that internal 
representation
>> of colorimetric samples (pixels). It's also about constraining color 
palette
>> and disabling options that don't make sense in specific color model. 
These
>> constrains are not the means of limiting designer's freedom of 
expression
>> but the means of preventing his/hers involuntary mistakes. If I'm 
preparing
>> grayscale illustration for print I don't want to leave there some 
"blue sky"
>> because I forgot I can't use color.
>>
>> Of course it can be done during export, but if one forgets about 
"grayscale
>> conversion" during export all of it is of no use anyway. Besides 
what does
>> it mean "convert to grayscale"? There's a multitude of conversion 
methods
>> which would have to be implemented anyway. What if designer would decide
>> automatic conversion does not satisfy his needs? He would have to 
come back
>> to canvas and fix something that could be done properly from the 
start if
>> color modes (or some kind of constraints) were in. And what about "soft
>> proof" based on dot gain?
>
>
> These days I am not spending mentionable time developing GIMP or
> GEGL, but I am eagerly awaiting GIMP to get further; and hopefully as
> that happens contribution to both GIMP and GEGL will pick up.

My hopes exactly.

> I'll
> briefly respond to your concerns even though these is things that have
> been brought up and addressed many times before.

Appreciate your kindness and patience! I'll do my best to not to strain 
them.

> For both restricted gamuts, like late binding conversions with
> ICCprofiles to CMYK, specific low bitdepth palettized images, not
> spatial global grayscale conversions and more.

I've had a discussion some time ago on this list about what ICC profiles 
can and can't do in regard to CMYK images and if CMYK color model is 
still significant. Shortly: potentially – ICC's can do everything, 
practically – it's easier to do some things "by hand" binding early.

> Soft proofing will be
> the way to go about it, by having a live preview of the result of
> the manipulation.

Soft proofing is a must – I agree.

> How the data is dealt with internally should not need
> to be a concern of the content creator - the intended output should
> be.

That's true, but internal data architecture influences content creator 
indirectly. He may not care if we're using floats or integers - he cares 
only about nice resulting image, but he is affected by more or less 
efficient handling of chosen data types and by memory size required to 
work with them comfortably. Two data structures may give exactly same 
results on preview and export, but using more memory hungry one will 
mean for designer that he can use less e.g. layers before his system 
will be forced to use swap file and become sluggish. And – I think we 
can agree on that one – more responsive tool *is* better tool.

Mind you – I assume, in the light of previous discussion (voice to get 
rid of color modes completely), that *all* images in GIMP are to be, 
regardless of their destined color space or model, internally stored as 
32 bpc fp RGBA images. Such data structure is not only assumed for their 
manipulation, but for their whole life cycle inside GIMP. That's my main 
concern.

>(As many tools as possible should also work regardless of the
> intended output, currently random plug-ins refuse to work in RGB,
> Grayscalewith or without alpha in indexed mode etc.)

Yes. I agree that attempt to implement image operation "once and for 
all" is tempting (frankly I though about it some years ago but with 
using color model describing full visible spectrum), but I consider it 
to be only experiment. However interesting it may be, it may show some 
effects are implementable easier in model dependent manner. Some may 
even appear to be unimplementable in this newly conceived "common" image 
manipulation space. I don't know. I don't think anybody does, before 
actually experimenting with that idea.

My best regards!
thebodzio