Wide color channels in Gimp

[John Moser]

After discussing with some graphics people in the community, it has come to my
attention that Gimp only supports 8 bits per color channel (bpc), totalling 32
bits RGBA. Architecturally, Gimp is not easily expanded to wider color channels
such as 16 or 32 bpc; however, it is possible. Previously, some developers
created a program called "cinepaint," a Gimp fork that supported 16 and 32 bpc
color spaces. Unfortunately the project eventually halted and does not support
the range of features of newer Gimp.

* http://cinepaint.sourceforge.net/

Although humans can't tell the difference between 8bpc and 16bpc, mathematical
algorithms can. In particular, certain mathematics used to touch up images or
blend colors can result in a visual artifact called "banding," where visible
differences in lumance appear in the image where there previously were none,
often resulting in what look like bands of areas with different gammas or
brightnesses. To prevent this, the color space can be increased so that the
bands occur over ranges so small that when reduced back to 8 bpc color space,
they are lost with the extra information in the other 8 or 24 bits. In other
words, rounding is saved for the end of the process.

To achieve the best effect, images should be stored and operated on in a full
range color space. Rounding down to an 8 bpc color space should only be done
when the image is finally exported to a standard 24 or 32 bit format such as
PNG, MNG, or JPEG. This allows the results of previous large color space
operations (i.e. image effects such as blurring and glass lenses) to retain
their extra information so that more effects can be added on top of them without
visible artifacts, further reducing or even eliminating banding.

This bug should not be a high priority, as it would require the Ubuntu
developers to massively patch the internal architecture of Gimp, and then to
convince the Gimp mainline developers to accept the patches. Historically, the
Gimp mainline developers apparently have inverted interest in (i.e., will fight
against) widened color spaces; however, professional graphics artists understand
that at least 10 bpc of color space (i.e. 40 bit instead of 32) are needed to
produce quality images, and hence have been moving off Gimp and onto Photoshop.
 Bigger is better; even high-end 3D graphics cards operate in 128 bit color
(32bpc) (as noted in John Carmack's .plan file from when he was writing Doom3).

[John Moser (nigelenki)]

Created an attachment (id=2143)
Base image for illustration

This image came from
http://www.panicstruckpro.com/revelations/cavern_shoot.html

I am going to sharpen it 10 times in gimp (8 bits per channel) and 10 times in
CinePaint (a hacked up version of an old version of Gimp, with support for 16
and 32 bits per channel) using 16 bits per channel unsigned integers. Results
will be attached as png.

[John Moser (nigelenki)]

Created an attachment (id=2144)
sharpened 10 times in gimp

This was sharpened 10 times in Gimp with a sharpness of 50 from
filters->enhance->sharpen

[John Moser (nigelenki)]

Created an attachment (id=2145)
cinepaint shot.

odd, i'm getting the same results in cinepaint. I just did this on a blown-up,
gauss-blurred copy and got better results but about 10 times more memory usage;
but I don't want to attach 400k png images.

Well, the cine paint one certainly looks more continuous at least; but I was
shooting for looking like the original image. I'm not a graphics professional
though so *shrug* I can still justify stuff mathematically.

[John Moser (nigelenki)]

This is upstream's job, why did I put this here? They're working on this
anyway. . . .

[Alan Horkan (horkana)]

> "cinepaint," [...] Unfortunately the project eventually halted

Cinepaint never halted development. there are working on a branch called Glasgow which amongst other things change the program to use FLTK instead of GTK. The cinepaint developers do make some efforts to make it relatively easy to part features from the gimp, you might want to contact them if you have specific questions.

The developers of the GNU Image Manipulation Program are working on a new image processing backend called GEGL to provide the greater colour depth you are hoping for.

Not sure how any of this fits in with Ubuntu, as I do not believe they are likely to take on the work of massively redevloping the infrastructure of the GNU Image manipulation program. I would recommend the Ubuntu bug team refer this upstream or (since upstream are already working on it) close this report.

[Troy James Sobotka (troy-sobotka)]

I wanted to bump this bug report with the news that Cinepaint is now considered unmaintained in Debian / Ubuntu and is possibly (?) not going to be included in Hardy.

I will say beyond a shadow of a doubt that lacking _any_ application to do realtime manipulations in interfaces that are _close_ to Photoshop will hurt Ubuntu uptake.

Every single DSLR camera on the market today offers the ability to shoot in RAW mode. While wonderful tools such as dcraw exist to push this into a usable open TIFF format, there will be no 'Photoshoplike' tools to manipulate the data. This is problematic.

Blender can and will operate on these bit depths, but differ dramatically in the ease of slider based interfaces that most 'average' DSLR users would probably prefer.

The GIMP developers have put 16 bits per channel and greater resolutions on the "unimportant" list for too long I fear, and we are now going to be faced with the very real smashing of reality (DSLR users almost exclusively use RAW manipulations in the deeper colour depth and they are becoming ubiquitous) that Free Software and Linux are falling _far_ behind mainstream dollar store applications.

I urge anyone capable to attempt and seek resolution on this issue. It is _not_ a minor point as this also has huge implications in the feature film industry and its adoption of Linux. Having tools and infrastructure that operate on professional level bit-depths formats is vital to Free Software uptake, health, and simple practical 'every day' uses.

[sam tygier (samtygier)]

i believe the work to move GIMP to the GEGL backend has started. this will bring 16bit channel support.

You may also want to try out krita.

[Thomas Hotz (thotz-deactivatedaccount)]

When GIMP 2.10 is released then we will have this feature hopefully :)

[Thomas Hotz (thotz-deactivatedaccount)]

I'm setting this bug as "In Progress".

[madbiologist (me-again)]

This was added in GIMP 2.9.2. Ubuntu 18.10 "Cosmic Cuttlefish" was released with GIMP 2.10.6-2.