It's worth remembering that printing is almost universally still 8bit. However, it is clearly very important that any current image package should allow opening and manipulation of greater depth images. My own camera is a long obsolete Fuji S20 but it produces 12bit images. As a result all my post processing is done in ImageMagick and the GIMP is only of use in opening the final jpg fro cropping and printing.

But, 32bit and 64bit colour is effectively meaningless. It would certainly be useful for an image package to work internally in 32bit, and maybe even 64, so that the results of, for example, multiple layers with transparancy can be calculated without errors showing, but for both input (ie, taking the original picture) and output both 32 and 64 bit is a waste of time and probably money too.

TW

On Wed, 16 Jan 2008 10:25:39 -0000, 7willows wrote:

Hi,

As an in frequent GIMP user since v1.2, GIMP was used just cropping and resizing images. One of the computer magazines I picked up in a locale store had published an article on GIMP showing how to selectively colourise based on Eric R. Jeschke tutorial, which I tried.

In another magazine around the same time, a challenge was presented (no prize) to manipulate a series of images and I thought I would use GIMP to improve my knowledge of GIMP. While I suceeded in completing the challenge using GIMP it was tinged with disappointment that some of the images where downgraded from 16bit to 8bit images.

After having a trawl through the GIMP Development site and GIMPcon 2006 and the GIMP vision which I think is very good. As a very inexperienced GIMP user, the fact that GIMP can not handle a 16 or 32bit monochrome image immediately is a reason not to invest any more time in GIMP. The inexperienced user wants to load an image and generally crop and resize, then comes combining images. Eventually, more complicated manipulation is attempted unless a specific objective is required. Can I ask when 16 and 32 bit monochome images can be loaded?

As CPUs are now primarily 64bit (I am running Solaris 10 x86 as a 64bit OS) could the design of GIMP be adjusted so that maximum image bit depth becomes user selectable 32 or 64bit? As a lapsed programmer (only using sh and no compiled language for over 10 years) I fully appreciate it is not a simple fix.

On Wednesday 16 January 2008 07:58, Thomas Worthington wrote:

On Wed, 16 Jan 2008 10:25:39 -0000, 7willows

wrote:

As CPUs are now primarily 64bit (I am running Solaris 10 x86 as a 64bit OS) could the design of GIMP be adjusted so that maximum image bit depth becomes user selectable 32 or 64bit? As a lapsed programmer (only using sh and no compiled language for over 10 years) I fully appreciate it is not a simple fix.

Adding to Thomas answer: the larger integer size in CPUs being 64 bit has absolutely nothing to do with the pixel depth a program can use. One could write a program to manipulate images in which each pixel was represented by a 5 X 64 bit in an 8 bit machinne.

But, answering you both: yes, current gimp trunk is using GEGL for some color operations, which are them performed at 32bit floating point precision. Version 2.6, which will come out this year will implement that, but likely it won support saving in more than 8bit per channel.

If you are working with monochrome, and 16 bit final output formats would indeed make a difference, I suggest increasing your resolution by a factor of 2 or 4 to overcome this.

js ->

On Wed, 16 Jan 2008 13:49:59 -0000, Joao S. O. Bueno wrote:

But, answering you both: yes, current gimp trunk is using GEGL for some color operations, which are them performed at 32bit floating point precision. Version 2.6, which will come out this year will implement that, but likely it won support saving in more than 8bit per channel.

Surely it will support 16bit png output? Would that not be trivial given that it's a part of the standard PNG library?

TWW

On Wednesday 16 January 2008 12:01, Thomas Worthington wrote:

On Wed, 16 Jan 2008 13:49:59 -0000, Joao S. O. Bueno

wrote:

But, answering you both: yes, current gimp trunk is using GEGL for some color operations, which are them performed at 32bit floating point precision. Version 2.6, which will come out this year will implement that, but likely it won support saving in more than 8bit per channel.

Surely it will support 16bit png output? Would that not be trivial given that it's a part of the standard PNG library?

Yes, that would. The problem is that the internal image format in GIMP, while not executing an opertaion will likely be 8 bit still. Therefore, there would be no gain in saving it to 16bit.

but it might be that the developers start working with the layers in ahigher depth representation still in this cicl. OI fthat happens certainly there will be 16 bit save options.

js ->

TWW