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

[Bogdan Szczurek <thebodzio gmail com>]

W dniu 12-01-28 15:37, Øyvind Kolås pisze:
> On Sat, Jan 28, 2012 at 1:33 PM,<jcupitt gmail com>  wrote:
>> On 28 January 2012 06:10, Martin Nordholts<enselic gmail com>  wrote:
>>> 2. Make GIMP clever. If GIMP encounters a tile with only values 0.0
>>> and 1.0, the 32 bpc data can be transparently, i.e. without the user
>>> noticing, replaced with 1 bpc data. As soon as more bits of precision
>>> is required to avoid loss of data, GIMP can transparently convert the
>>> tile back to RGBA float. The same kind of optimization can be done for
>>> completely black, white and transparent tiles too.
>>
>> This sounds nice, though the problem with this approach is that you
>> need to scan each tile to work out what format it can be compressed
>> to.
>
> Instead of replacing tiles with 1bpc data, one can either compress the
> tile contents (trading of cpu use for io amount) or do a more generic
> de-duplication through hashing at runtime (based on an idle job
> combined with tracking revision numbers on tiles). Both are things
> that fit well in the GeglBuffer architecture, though the runtime dedup
> could have a rather large runtime cost.
>
> Such streaming compression of tile data as it is saved/loaded wouldn't
> be much slower than the current implementation. Though it likely be
> quite a bit slower than a mmap backed thing with a threaded tile
> writer.. (the hdd eating monster consumed a hdd with an almost working
> such implementation last year).

-- cut --

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?

My best!
thebodzio