W dniu 12-01-28 20:47, Øyvind Kolås pisze:
> On Sat, Jan 28, 2012 at 7:23 PM, Bogdan Szczurek<thebodzio@xxxxxxxxx>
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
_______________________________________________
gimp-developer-list mailing list
gimp-developer-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gimp-developer-list
