GNOME Bugzilla – Bug 74224
Add support for 16 bits per channel
Last modified: 2012-05-28 14:58:30 UTC
Hi I don't know how to check if gimp is working with files (for me they were tiff files) with 48 bits pre pixel? I know it reads them without any problems (48 bit tiff files), but it looks like it converts them to 8 bits per channel and works with such an shallow color depth. It is a major problem for everyone who seriously treats his photos scanned on good scanners. Simply after a very few image enhancements one can see on histogram that it lacks some values. It is due to process only at resolution of 8 bits of image data. What I generally want is very good tool for photographs' manipulation. Currently gimp is only good ;-( Regards Piotr Legiecki
Currently, the GIMP supports only 8 bits per channel. The support for 16 bits per channel has been planned (several years ago) for inclusion in GIMP-2.0. In December 2000, Sven&Mitch posted a proposed roadmap for the future of The GIMP. You can get it from: http://developer.gimp.org/ This feature has been on the TODO list for a long time, but I could not find any bug report about it, so this will be the one... I have changed the title accordingly.
About the colour mode, I don't really know what are their official name, but there shoul be a choice between : Indexed (<256 colours ???) colours 8 bits/channel colours 16 bits/channel greyscale 8 bits/channel grayscale 16 bits/channel CMYK ...
Will Cinepaint developers directly participate to Gimp development ?
The CinePaint developers are doing their own thing and don't seem to be interested in sharing any code. GIMP will use GEGL to improve it's support for color models (see http://www.gegl.org/).
*** Bug 125302 has been marked as a duplicate of this bug. ***
Raising priority of this report so people don't get the wrong impression we would not care.
*** Bug 133371 has been marked as a duplicate of this bug. ***
Has the status changed with version 2.0.x or 2.1.x?
Digital photography editing is becoming more and more popular. Digital SLR and prosumer cameras these days can output 48 bit color images. Not many tools exist in Linux to support the editing of these images.
We are well aware of the need for higher color depths. If you want to push it, adding comments here won't help. But you could join the gegl-developer list and offer your help there.
Is this feature planned for version 2.3.x or 2.4.x ? Cheers, Peter
No. GIMP 2.3.öx is the current development branch and will be released as 2.4 when it is ready. While features might still be added to it, something as big as the transition to higher bitdepths is not planned for this release. This will cause serious side effects for a few months - for example, it's likely that most plug-ins will have to be changed - and we can't do this at this stage of 2.3.x. Work on GEGL has been started during our meeting at GUADEC this monday, though. So there should be a usable roadmap and better defined set of taks that have to be done in order to get it working.
Cool. Hopefully these are the right URLs to go with the bug: http://cvs.gnome.org/viewcvs/gegl/?sortby=date https://lists.xcf.berkeley.edu/lists/gegl-developer/
*** Bug 306897 has been marked as a duplicate of this bug. ***
Note that the gegl-developer list has been dead since August 2003. See for yourself: https://lists.xcf.berkeley.edu/lists/gegl-developer/ At least, that's the gegl-developer list Google knows about. If there is some non-dead version of this list, adding links all over the place would be very helpful.
All archives at berkeley are dead for a long time, that is a well-known fact. And it isn't actually that difficult to find a working archive of the gegl-developer list.
I am working on a project that started using GIMP but I have to change as GIMP is stuck in the dark ages of 8 bit channels. I don't have the color resolution to make the necessary changes. This is a painful move. I have tried the to do the same thing with only 8 bit and I cannot achieve the necessary and required quality. :( I searched through the GEGL links and I cannot find any references to when and if any higher resolution will be added. I have looked at CinePaint and came across this article. http://cinepaint.bigasterisk.com/ComparingCinePaintAndGEGLGIMPArchitectures CinePaint which started off from GIMP has this on their home page. "CinePaint is different from other painting tools because it supports deep color depth image formats up to 32-bit per channel deep." I wonder if the GIMP developers have even considered that the wait for GEGL could be a costly mistake into the future of GIMP. When GIMP supports at least 16 bit channels, I can start promoting it again.
Instead of stopping "promoting" GIMP, why don't you just start hacking a bit and help us getting out of the "dark ages"? Don't you think that would be more effective on our motivation as volunteers than "wondering" about the "mistakes" we made or even quoting Robin Rowe's rants about hopelessly outdated stuff?
Re comment #16: It actually is that difficult: neither googling nor the gegl.org pages give anything except the old xcf archives. Perhaps this can be corrected?
Not sure if this is the right place for it, but is it really a good idea to set up yet another image processing lib project? Perhaps it would be more productive to join forces with other efforts, such as VIPS - see http://www.vips.ecs.soton.ac.uk/
Is there any advance in this issue ? It's a big pity for people completely wanting to use their cameras raw format.. And look at the competitor krita, it already has up to (I think) 64bit per channel support, though no raw import yet (which is ufraw for gimp).
GIMP is a great tool. But the lack of 16 bit per chanel degrades it onto paintbrush level for photo editing.
No need to tell us. And yes, there is advance in this area. Any help with it is appreciated.
What is the area where help is needed the most (e.g. bringing GEGL up to speed, porting GIMP code to use GEGL, ...)? I can't promise anything, but as a user (well, packager) I'd like to see the advances you talk about -- if there is anything I can do coming "from the outside" (i.e. not very much in the know about GIMP code internals) and there is time I'd like to be of help.
I'm also one of the photographers which really need 16 Bit, and I'm also always tempted to change to a Mac in order to be able to use Photoshop. But I really would prefer to stay on Linux and continue using the Gimp. I'm willing to contribute as I can, but the answers from Sven or Michael are not really helpful. It's pretty much impossible for anybody who's outside the project until now to just check out the sources, dive into them and find out where to do anything about this. Since the 16-Bit issue is obviously one of the three main future plans (the other being CMYK and color management, at least according to german wikipedia), I would appreciate a complete and concise summary of the current state of this topic, a list of current problems and places where to start contributing. As long as this doesn't exist, you simply cannot expect anyone to "just start hacking". Maik
http://www.gegl.org/ has quite a bit of information, including a TODO. The code can be checked out of CVS in the gegl and babl modules. If you have further questions, please ask them on the gegl-developer list.
Follow the http://www.gegl.org/ link provided in comment #26, then click on the "Mailing Lists" link in the left navigation bar. Note the gegl-developer@lists.xcf.berkeley.edu address. Now look at comment #16 here, which was a response to comment #15 or comment #13. Supposedly it "is a well-known fact" that the "archives at berkeley are dead for a long time". Despite this, gegl.org is still pointing at them. Huh? See also bug #307059, where I filed a bug report about the web site. Are there in fact no working archives? It's kind of hard to find the gegl-developer mailing list when all the web sites point to some old thing that is dead.
I don't recall any messages in February so far, and the other list archives on this system are working again. Maybe you should send a test message and check if it gets archived?
*** Bug 339359 has been marked as a duplicate of this bug. ***
*** Bug 354948 has been marked as a duplicate of this bug. ***
*** Bug 385617 has been marked as a duplicate of this bug. ***
*** Bug 410083 has been marked as a duplicate of this bug. ***
*** Bug 432927 has been marked as a duplicate of this bug. ***
Can anyone outline the problems or changes needed to bring 16 bit support into Gimp? This would be most useful for scientific applications, where cameras typically output >12 bit per channel data. I would like to know the difficulty of implementing such a concept into gimp. Thankyou
We have a clear idea on how to get 16 bit support into the GIMP. Have a look at GEGL and you'll learn about our approach. Won't happen for Gimp 2.4, will happen for Gimp 2.6. Please understand that bugzilla is not a forum like discussion board, hence the terse answer.
*** Bug 466040 has been marked as a duplicate of this bug. ***
*** Bug 469654 has been marked as a duplicate of this bug. ***
*** Bug 498061 has been marked as a duplicate of this bug. ***
*** Bug 504516 has been marked as a duplicate of this bug. ***
Hello, What about the target milestone, is this feature planned for version 2.5.x, 2.6.x or later? Cheers, Peter
Later.
*** Bug 538728 has been marked as a duplicate of this bug. ***
*** Bug 82267 has been marked as a duplicate of this bug. ***
Created attachment 127235 [details] [review] gimp-16-bit-2009-01-26.patch The patch makes the core override the PNG save and load plug-in procedures and then uses GEGL to load and save PNGs. Using the data of the PNG the core creates an image with a layer using a new trivial core internal API for creating images and layers for arbitrary babl formats: gimp_image_gegl_new() and gimp_layer_gegl_new(). The GimpDrawable have been given a GeglBuffer backend that is used for the layer data, and GimpOperationTileSource and GimpOperationTileSink are adapted to use the GeglBuffer backend when available. The GimpImageMap component have also been adapted to use GeglBuffer data of drawables when available. No changes to the plug-in API have been made. All in all this allows to open a 16-bits-per-channel PNG, color correct it with the ported operations under the Colors menu, and then save it back as a 16-bit PNG. Note that in order to work with 16-bit PNGs with the patch you must enable GEGL for the projection and the color tools, i.e. do View -> Use GEGL and Colors -> Use GEGL. The code is rather crude and leaks buffers and memory, but quite interesting nevertheless. Let's consider adding some kind of 16-bit support for 2.8.
The way that loading and saving is delegated to the core needs to be changed. But let's discuss that on the mailing-list.
Created attachment 127711 [details] [review] gimp-high-bit-depths-2009-01-01.git.patch Here is a series of git commits that makes it possible to open an image and convert the data to 32-bpc by doing Image -> Bit Depth -> 32 bits/channel. It should give a pretty good indication of what the final code that I am working on will look like. If this seems to be in the completely wrong direction, please eek.
*** Bug 574415 has been marked as a duplicate of this bug. ***
After working on this for a while my conclusion is that it is too early; implementing this now would require to much "temporary code" to be written. I will revisit this for 2.10.
I started using imagej, written by someone at nih. It can display 12-bit, 1344 by 1024 PGM images great. You should see how its done in there.
(In reply to comment #49) > I started using imagej, written by someone at nih. It can display 12-bit, 1344 > by 1024 PGM images great. You should see how its done in there. I'd say the issue isn't that GIMP developers don't know how to handle images with more color-depth, but that there's a huge amount of code in GIMP which hasn't been migrated to the new way of things that can handle depths other than 8 bits per channel (gegl). Martin, can you outline what the big picture "construction sites" in GIMP are that need to be finished first? I know I would like to help (with my little knowledge about GIMP innards), but wouldn't know where to start, perhaps others are in the same situation... Are there recipes for e.g. converting plugins to the using GEGL (or whatever else needs to be done to make them work mith other than 8bit color depths?
One currently unfulfilled requisite is that we get rid of GIMP's TileManager and start using GeglBuffers instead. Implementing higher bit depths on the current code base would require us special-case the existance of the TileManagers in a lot of place and its just not worth it. If anyone is interested in code I have, come by #gimp on irc.gnome.org and we can arrange a fetch of my git branch.
I'm basically interested, but will be on vacation from tomorrow on for 3 1/2 weeks. I'd like to look at it afterwards.
Hm... fixed in git-master? ;)
Yes, basically fixed.