Re: [Gimp-developer] Image color representation?
On Fri, 27 Jun 2008 17:07:32 +0200, David Gowers [EMAIL PROTECTED] wrote: Hi solar, On Fri, Jun 27, 2008 at 11:32 PM, [EMAIL PROTECTED] wrote: On Fri, 27 Jun 2008 03:02:01 +0200, David Gowers [EMAIL PROTECTED] 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. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image color representation?
Hi solar, On Fri, Jun 27, 2008 at 11:32 PM, [EMAIL PROTECTED] wrote: On Fri, 27 Jun 2008 03:02:01 +0200, David Gowers [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image color representation?
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! :)
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?
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?
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?
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?
--
View this message in context:
http://www.nabble.com/Image-color-representation--tp17855048p17871475.html
Sent from the Gimp Developer mailing list archive at Nabble.com.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image color representation?
David Gowers wrote: 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. I should take a look a that library, it seems quite handy. Thanks for the tip! -- View this message in context: http://www.nabble.com/Image-color-representation--tp17855048p17871593.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image color representation?
On Fri, Jun 27, 2008 at 4:41 AM, TriKri [EMAIL PROTECTED] 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.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image color representation?
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 [EMAIL PROTECTED] 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. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image color representation?
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/ ) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
