On 5/17/07, Mark Probst <mark.probst@xxxxxxxxx> wrote:
> On 5/17/07, Øyvind Kolås <pippin@xxxxxxxx> wrote:
> > I think we want a bit more functionality similar to the one already
> > existing in GIMP as well,
> > for instance making sure the values always add up to 1.0 to maintain
> > the range in the image
>
> I don't think that's a good idea. First of all, ensuring that they
> add up to 1.0 does not guarantee that the mono range stays withing
> 0.0-1.0 (if the red weight is 2.0 and green and blue are -0.5, then
> pure red will get a value of 2.0, while pure green and pure blue will
> get values of -0.5). Second, sometimes values which don't add up to
> 1.0 give useful ranges anyway. In practice you have to make such
> adjustments by looking at the resulting histogram. And limiting the
> weights to non-negative numbers won't do either. Here's an example of
> a photo that I made using negative weights:
The color mixer in gimp doesn't make sure they add up to 1.0 but makes
sure the output range is 0.0-1.0. But it might be that one requires
pre-normalized data for this to work correctly.
To provide full control over such a global color to gray scale mapping
is the ability to
position a grey axis within the RGB cube that the colors a projected
upon. To specify this
you would either need 6 values. Without having 6 values to do it, you
will need additional
levels adjustment to get the resulting values in the 0.0-1.0 range. It
is possible to find the
optimal orientation of this grey axis, making sure that the
distribution of the resulting histogram has the best possible spread
(not necessarily optimal esthetically, but optimal in
getting the most amount of detail out of an image).
> A question, though: Does an operation have to make sure that the
> values it produces are within the 0.0-1.0 range?
No, it should be prepared to receive and produce values in the -inf ..
inf range.
> What other requirements would there be for making it a "proper" operation?
None really, but I do not want to introduce it amongst the operations
in the default install until we have some confidence that it will not
need to change much, since adding it to the default set of operations
defines new API, there is even some existing operations I want to
relocate before the next release.
When it comes to adding specialized support for grey scale formats, I
am afraid that will
have to wait. At the moment almost all operations read and produce
RGBA, and there is no addiitonal negotiation logic as to which formats
should be chosen. When such logic is added ideally the 32bit floating
point RGBA implementation should remain unchanged and additional
optimized variants using SIMD instructions, for particular pixel
formats and similar register as alternate versions (that can be
regression tested against the RGBA version). Exactly how this will be
implemented is still unclear since there are further pending changes
in the core of how GEGL does it's processing and what is demanded of
operations.
/Øyvind K.
--
«The future is already here. It's just not very evenly distributed»
-- William Gibson
http://pippin.gimp.org/ http://ffii.org/
_______________________________________________
Gegl-developer mailing list
Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
