Gimp currently uses 8bits/channel. Some 16/12bit formats (eg TIFF) are supported only by scaling the data down into 8 bits.

The colors used in color selectors, and 'single' colors are represented as floating point values.

I suggest investigating GEGL (gegl.org), which can provide pixel data in a wide range of formats, and load images, if you require >8bpp support. GIMP 2.5+ already depends on GEGL.

(also, with a 256-entry lookup table, converting 8bpp->float is trivially easy and fast to implement)

On Mon, Jun 16, 2008 at 8:25 AM, TriKri wrote:

Hi!

I am wondering which data type GIMP uses to represent the color in a pixel of an image? 8 bits/channel? 12 or 16 bits? float?

According to http://pippin.gimp.org/image_processing/chap_dir.html#id2525344, there seems to be some different representation types, but glaus is somewhat unknown to me, though.

I'm having a bit of trouble myself deciding which type I should have in the program I'm going to make, to use for each channel. If I use 8 bits per channel, the different functions will probably run a bit faster than if I use floating point values.

Premature optimization is the root of all evil. I know it's tempting, but it's really good practice to only optimize when a) there is something fundamentally wrong with the approach taken by the algorithm, or b) you have proof that that specific code is unacceptably slow (bottlenecking the process)

If you should, by chance, use floating point representation of the colors, is there some function in GIMP to read a jpg image directly into an image with floats, instead of using some function already existing to read it into an image with 24-bit color and then convert it to floating point values?

/Kristofer --
View this message in context: http://www.nabble.com/Image-color-representation--tp17855048p17855048.html Sent from the Gimp Developer mailing list archive at Nabble.com.

On Sunday 15 June 2008, TriKri wrote:

Hi!

I am wondering which data type GIMP uses to represent the color in a pixel of an image? 8 bits/channel? 12 or 16 bits? float?

Hi!

The gimop currently works with 8 bit per channel only.

According to
http://pippin.gimp.org/image_processing/chap_dir.html#id2525344, there seems to be some different representation types, but glaus is somewhat unknown to me, though.

I’m having a bit of trouble myself deciding which type I should have in the program I’m going to make, to use for each channel. If I use 8 bits per channel, the different functions will probably run a bit faster than if I use floating point values.

In a new program dealin gwith images, you certainly should take a close look in GEGL - the Generic Graphics Library - which has been though from the beggining as a library to enable GIMP to work in other color dephs in a clean way. Most likely, if your program needs to perform operations in an image you will be fine implementing these operations in GEGL thenselves, and then havign the remaning of the program as a UI around the GEGL calls (or even as a GIMP Plug-in if the users of your programs are likely to do other things with the images before or after your program do its thing on them)

If you should, by chance, use floating point representation of the colors, is there some function in GIMP to read a jpg image directly into an image with floats, instead of using some function already existing to read it into an image with 24-bit color and then convert it to floating point values?

yes, GEGL can do that for you (but not GIMP).

/Kristofer

js
->

(ps. http://www.gegl.org/ )

On Fri, Jun 27, 2008 at 4:41 AM, TriKri wrote:

David Gowers wrote:

I'm having a bit of trouble myself deciding which type I should have in

the

program I'm going to make, to use for each channel. If I use 8 bits per channel, the different functions will probably run a bit faster than if

I

use floating point values.

Premature optimization is the root of all evil. I know it's tempting, but it's really good practice to only optimize when a) there is something fundamentally wrong with the approach taken by the algorithm, or b) you have proof that that specific code is unacceptably slow (bottlenecking the process)

But gimp uses 8 bits per channel and gimp isn't evil? Oh, I see, THAT optimization is mature! :)

That's exactly correct. It's mature and out of date: It was an optimization that was definitely required at the time (running on 486s, small hard disks, etc..), and is no longer required in today's world of fast CPUs with fast FSBs, large memory, and huge hard drives. AFAIK no new GIMP code is being written that manipulates 8bpp sRGB integers, only 32/64bit scRGB floats/doubles (such as the new color processing ops (levels curves posterize etc.))

No to be honest, I don't really see your point. Do you mean I should use floating point values even though gimp uses 8-bit values?

I mean you should use whichever fits the way you are manipulating them best, without attempting to be clever or fast until you have determined for sure that the algorithym is not already clever or fast enough.

Usually, I expect the appropriate choice to be floating point, as it tends to be the 'least surprising' in it's behaviour. It's only a few filters (things like 'Gradient Map', which basically map the image data through a set of lookup tables), that would glean no benefit from using floats when the input image format is 8bit/channel integer.

Joao S. O. Bueno Calligaris wrote:

The gimop currently works with 8 bit per channel only.

Sorry, but I haven't heard of gimop before. :) Just kidding!

How does it come there is a structure GimpRGB in gimp that looks like:

typedef struct { gdouble r, g, b, a;
} GimpRGB;

if gimp only uses 8 bits/channel? Is this intended for representing some color other than those in image pixels?

Yes, it is used for passing around individual colors -- for example, the FG and BG color are stored in GimpRGB structures.

By the way, if gimp only 8 bits/channel, wouldn't there be bigger and bigger quality losses of the picture if one does a lot of manipulation and the functions used constantly are scaling down the values to 8-bits per channel?

Yes

Or is it hard to notice the rounding effects? I'm just curious, since you say you shouldn't save and re-load a jpg image too much, isn't this about the same thing? Maybe the idea is to implement floating point values and other more high resolution data types, to the channels when GIMP gets more dependent of GEGL?

Yes, it is. Integration of GEGL has begun, with 2.5 providing GEGL-based code for all the color adjustment tools (curve, levels,..) 8 bit / channel limitation will persist until all core parts of the GIMP code are aware, through GEGL, of differing pixelformats/colorspaces. This is a fairly massive set of changes needed before GIMP handles non-'8bpp RGB' image data gracefully, after which I expect we'll want to migrate as many plugins to support different color depths/spaces as possible. Various PDB functions will have to be deprecated (due to a) wrong assumptions that values range 0..255, and b) INT8 and INT8ARRAY parameters that are no longer appropriate) and functions to replace them created. Hopefully a major update of the PDB interface to provide things like default parameters, varargs, and keyword args will be done aside that ('rockwalrus' was working on this 'libpdb', I haven't heard news of it in some time)

That's why the overall timeframe for integrating GEGL is so long. HTH.

David.

Hi solar,

On Fri, Jun 27, 2008 at 11:32 PM, wrote:

On Fri, 27 Jun 2008 03:02:01 +0200, David Gowers wrote:

and is no longer required in today's world of fast CPUs with fast FSBs, large memory, and huge hard drives.

Easy on the sweeping assumptions here. Embedded systems are in exponential growth right now and correspond in performance to what you are quickly writing off as old and decrepid hardware that is best ignored.

Many embedded systems are reaching a power that allows them to be used for image and even video (CCTV) applications. It's unlikely, though not impossible, that you'd use such a system for GUI image manipulation but Gimp could conceivably be useful here for batch processing images or other tasks.

Be careful not to assume all target systems are like your average desktop PC.

GIMP doesn't run on embedded systems AFAIK (mainly because of its minimum screen resolution requirements.) In any case, what you said above is true and unrelated. GEGL seems a much better choice for batch manip generally, however even if you would use GIMP, nothing would force you to use high bitdepths.. GEGL allows you to make different versions of an operation for different data types / colorspaces, so you would perhaps need to make 8bit-optimized versions (more likely, GIMP would implement these itself already, since it's a common data type). The difference is that GIMP needn't make that assumption, and thus the overall application is more flexible, accommodating different color spaces and color depths in the one application transparently.

In short: optimization reflects an underlying assumption, and the assumption that 8bit is the only efficient choice is no longer true, therefore the optimization of assuming 8bit is no longer appropriate.

David

On Fri, 27 Jun 2008 17:07:32 +0200, David Gowers wrote:

Hi solar,

On Fri, Jun 27, 2008 at 11:32 PM, wrote:

On Fri, 27 Jun 2008 03:02:01 +0200, David Gowers wrote:

and is no longer required in today's world of fast CPUs with fast FSBs, large memory, and huge hard drives.

Easy on the sweeping assumptions here. Embedded systems are in exponential
growth right now and correspond in performance to what you are quickly writing off as old and decrepid hardware that is best ignored.

Many embedded systems are reaching a power that allows them to be used for
image and even video (CCTV) applications. It's unlikely, though not impossible, that you'd use such a system for GUI image manipulation but Gimp
could conceivably be useful here for batch processing images or other tasks.

Be careful not to assume all target systems are like your average desktop
PC.

GIMP doesn't run on embedded systems AFAIK (mainly because of its minimum screen resolution requirements.) In any case, what you said above is true and unrelated. GEGL seems a much better choice for batch manip generally, however even if you would use GIMP, nothing would force you to use high bitdepths.. GEGL allows you to make different versions of an operation for different data types / colorspaces, so you would perhaps need to make 8bit-optimized versions (more likely, GIMP would implement these itself already, since it's a common data type). The difference is that GIMP needn't make that assumption, and thus the overall application is more flexible, accommodating different color spaces and color depths in the one application transparently.

In short: optimization reflects an underlying assumption, and the assumption that 8bit is the only efficient choice is no longer true, therefore the optimization of assuming 8bit is no longer appropriate.

David

Hi, thanks for the reply.

IIRC the original comment here was about removal of a structure used for storing 8 bit colours. Maybe that structure should be maintained as a build option.

I agree about assumptions. My concern was that the assumption does not become:

and is no longer required in today's world of fast CPUs with fast FSBs, large memory, and huge hard drives.

today's world is much broader than intel based PCs.

regards.