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

[Øyvind Kolås <pippin gimp org>]

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).

/Øyvind K.
«The future is already here. It's just not very evenly distributed»
                                                 -- William Gibson
http://pippin.gimp.org/ ;                           http://ffii.org/