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: 
Sent from the Gimp Developer mailing list archive at Nabble.com.

Gimp-developer mailing list

Reply via email to