On Sunday 25 January 2009 21:53:54 Martin Nordholts wrote:
> I have attached a patch to "Bug 74224 – Add support for 16 bits per
> channel"  that makes it possible to use GIMP for opening, color
> correcting and saving 16-bits-per-channel PNGs using the operations
> under the Colors menu that are ported to GEGL such as Color Balance or
> Levels. For a technical description of the patch, refer to the bug report.
> This was a weekend hack and raises an interesting question: shall we go
> for some kind of 16-bit support for GIMP 2.8? I think we should as I am
> confident we will be able to come up with something useful in the realm
> of high bit depths for 2.8. I don't think it will be hard to add support
> for loading some additional 16-bit image formats, allowing creation of
> 16-bit images and adding 16-bit capabilities to a set of basic tools.
> Even if we certainly won't be able to completely port everything to
> 16-bit in one release cycle it would show that we are making progress in
> this area. Just being able to color correct 16-bit PNGs covers one use
> case already.
I think Martin's proposal has merit. I know that comparisons to Photoshop are
to some extent considered off topic here but in this case I will do it because
the history of Photoshop has some parallels. The approach that Martin is
advocating (IE. having high bit depth support for loading, saving and some
color correction operations) is how the first versions of Photoshop with high
bit depth support worked. This started with version 6 I believe and the
support for high bit depth images improved with each follow on version until
it was complete. Even though these earlier versions were somewhat frustrating
because only some operations were supported for high bit depth images it was
none the less a significant step forward and this progress was well received
by it's users. I am sure that that would also be the case for GIMP users.
> To convince yourself of that the patch actually makes GIMP do stuff in
> high bit depth:
> 1. Apply the patch, requires SVN trunk of GIMP, GEGL and babl.
> 2. Open a 16-bit PNG with a white-to-black gradient such as this  one
> I created using Krita.
> 3. Enable GEGL for the projection and color tools, the legacy code can't
> handle 16-bit image data. View -> Use GEGL and Colors -> Use GEGL.
> 4. Use Colors -> Levels and map the entire range of input to the output
> range [120, 135]. This will make the image look completely gray. Apply.
> 5. Use Colors -> Levels and map the input range [120, 135] to the full
> output range [0, 255]. Apply.
> After doing 5 the gradient will look intact if you do this on the 16-bit
> PNG with GEGL. If you do this on 8-bit data using the 8-bit legacy code
> paths the results will look terrible.
> Welcome to the start of the 16-bit GIMP era ;)
Just curious. Since GEGL has support for more high bit depth formats than
just 16 bit int/channel how much more work would be needed to support a wider
range of formats? For example tif files can use a number of different
representations including 32 bit int/channel and 32 and 64 bit float/channel
as well as 8 and 16 bit int/channel and probably some other representation
formats. Once 16 bit int/channel is working how much additional work is
needed to support these other image formats? Or is this trivial to implement
and therefore almost free at that point?
Gimp-developer mailing list