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

[jcupitt gmail com]

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.

It's probably quicker to work out what format the various
intermediates should be in by static analysis of the pipeline of
operations. For example, a threshold operation can only ever output 0
and 1 (over threshold, under threshold) so you can always have a 1-bit
image coming out of it. If the next operation in the pipeline is
something like dilate, which works on binary images, you can directly
join the two operations up.

Another useful and related optimisation is to delay the conversion
from u8 to linear float as long as possible. You keep the original u8
image about plus the u8 to float LUT. For many unary pointwise
operations on the image (like threshold or level adjust) you can
simply manipulate the LUT and not touch the image at all.

John