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

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!

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