On Fri, Jun 27, 2008 at 4:41 AM, TriKri <kristoferkrus@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
