Just checking if this works...
Testing 1 2 3

Hey all, I was wondering about the development status of a 16-bit (or more) per channel rendering pipeline. It seems because of the ammount of layers and effects Im doing for an image, its degrading the final image quality because Gimp is only 8-bit per channel. It would be nice if 1.3/2.0 gets it, or even 1.2 if it wouldnt be too hard.

Erm, dunno why this didnt reply to the list. To those who missed stuff, I asked "Is it easy to add 16-bit per channel support to gimp?" the answer was "No it isnt."

But yeah, Film Gimp has issues. The xcf loader plugin doesnt work at all on x86 (known bug) so thats why I turned back to Gimp to see if I could get it here. (I do all my graphics artwork in Gimp.)

This might sound a little dumbassish on my part, but why wasnt 16-bit support added earlier? As far as I know, even Photoshop 6 doesnt have this (and when in native 16-bit mode, I cant get it to do layers at all.) And, yes, its hard to do now, but it wouldnt have been as hard in gimp 1.1 when it was in heavy development mode. Now of course, this would force all gimp 1.0 plugins to break (assuming the majority didnt already.)

Though, my method wouldnt break any plugins, however. Any plugin accessing the data would get back 8bit values because the layers are still in 8bit mode, its only a higher precision rendering engine that would be added. 8 bit goes in, 8 bit comes out, but its 16 bit in the middle. (And yes, when dealing with 20+ layers, all doing things other than Normal mode, and sometimes bringing the darkest color below 0,0,0, and the lightest color above 255,255,255, it comes in handy.)

On 11-Nov-2002, Raphaël Quinet wrote:

On Mon, 11 Nov 2002 05:44:52 -0500, Patrick McFarland wrote:

Hmm, that todo is pretty cool. But Is there any way to push 16-bit rendering earlier? Or is there any other sane way to do this?

The easiest way to push the 16-bit rendering earlier is to write the code and submit it to the developers. Alternatively, if you cannot program yourself, you could try sponsoring someone.

If you are only interested in getting 16-bit support but you do not care about all plug-ins and new tools that were introduced since GIMP-1.0, then you can try http://film.gimp.org/ or http://filmgimp.sourceforge.net/. This will give you the 16-bit rendering that you are looking for, but this version of the GIMP has slightly older tools and less plug-ins than the ones you get in the current stable version of the GIMP.

I dont know how the rendering pipeline works, but wouldnt it be relitivly easy to switch all the 8 bit variables with 16 bit ones, and just cut the final down to 8 bit for display, plugin data reading, and layer flattening?

No, it is not so easy. There is a lot more to be done than that: with 8 bits per channel, the RGBA pixels (R, G, B + Alpha) can be stored in a 32-bits integer ("int" or "long" in C) and this is done in many places in the core of the GIMP as well as in the plug-ins. With 16 bits per channel, this would require a 64-bit integer, which is not available natively on many platforms. So a lot of code has to be re-designed. In addition, many parts of the code for calculating pixel coordinates and other things (mapping the coordinates to the position of the data in memory) would have to be changed. Even if the changes are not always big, there are still several thousands of lines of code that have to be changed.

-Raphaël

P.S.: You sent your reply directly to me. You could have sent it to the list as well, because I assume that some other people could be interested.

Hmm, mutt doesnt seem to like me today, because yet again I have replied to someone, and it replied to them and not the list. =|

What I replied is as follows:

Hrm, well, whatever works, you know? I thought 16-bit per channel would have been enough, but if you wanna do 32-bit per channel, go ahead. (It should render beutiful images up high like that) All we need is someone that would want to add it.

On 11-Nov-2002, larry@marso.com wrote:

The right way to support 8-bit is having 16-bit support for interim calculations, and the right way to support 16-bit is having 32-bit for interim calculations.

Of course, when you're talking about workflow with complex transformations and multiple steps, "interim" is meaningless -- you need full support for the higher bit calculations.

If an effort to support 16-bit is underway and is serious, there should be IMHO support for 32-bit. For example, to sharpen in the luminance channel of LAB mode, one would want to take a 16-bit image, decompose into 32-bit channels, apply the sharpening to the LAB channel, and recompose, at which point you would transform back into 16-bit.

Such a procedure makes the channel transformation "lossless". Without 32-bit interim support, it's "lossy". (The same phenomenon renders all sorts of 8-bit transformations in complex workflows very poor in the current generation of gimp).

My 2 cents.

On Mon, Nov 11, 2002 at 08:13:53AM -0500, Patrick McFarland wrote:

Though, my method wouldnt break any plugins, however. Any plugin accessing the data would get back 8bit values because the layers are still in 8bit mode, its only a higher precision rendering engine that would be added. 8 bit goes in, 8 bit comes out, but its 16 bit in the middle. (And yes, when dealing with 20+ layers, all doing things other than Normal mode, and sometimes bringing the darkest color below 0,0,0, and the lightest color above 255,255,255, it comes in handy.)

Yep, mutt is going to die. Yet again it refused to reply to the list and instead replied to just the person.

Reply is as follows:

On 11-Nov-2002, Sven Neumann wrote:

Hi,

Patrick McFarland writes:

Erm, dunno why this didnt reply to the list. To those who missed stuff, I asked "Is it easy to add 16-bit per channel support to gimp?" the answer was "No it isnt."

But yeah, Film Gimp has issues. The xcf loader plugin doesnt work at all on x86 (known bug) so thats why I turned back to Gimp to see if I could get it here. (I do all my graphics artwork in Gimp.)

This might sound a little dumbassish on my part, but why wasnt 16-bit support added earlier? As far as I know, even Photoshop 6 doesnt have this (and when in native 16-bit mode, I cant get it to do layers at all.) And, yes, its hard to do now, but it wouldnt have been as hard in gimp 1.1 when it was in heavy development mode. Now of course, this would force all gimp 1.0 plugins to break (assuming the majority didnt already.)

it does indeed sound dumbassish. It also this sounds like you are volunteering to contribute. Why haven't you done that when 1.1 was in heavy development mode? Why don't you do it now?

The real reason? My C code isnt exactly the worlds best. (Aka you dont want to run it in a production app, ever.) And I dont have much time anymore. Im trying to find a job, which is eating up alot of my resources, and also with my current computer, it really kills my productivity rating.

But yeah, if I could get those out of the way, I wouldnt mind helping.

Though, my method wouldnt break any plugins, however. Any plugin accessing the data would get back 8bit values because the layers are still in 8bit mode, its only a higher precision rendering engine that would be added. 8 bit goes in, 8 bit comes out, but its 16 bit in the middle. (And yes, when dealing with 20+ layers, all doing things other than Normal mode, and sometimes bringing the darkest color below 0,0,0, and the lightest color above 255,255,255, it comes in handy.)

we don't really care about the plug-ins and there will probably always be such an 8bit compatibility mode like the one you suggested here. The hard part is to do the necessary changes to the GIMP core. Since there are effectively only a handful of developers working on The GIMP and the code base is huge and used to be chaotic and fragile, this is not a trivial job. It will be addressed as soon a 1.4 is out. Well, actually someone could start to work on the 2.0 core based on GEGL right now while we are busy to finish 1.4.

Salut, Sven