Re: [Gegl-developer] [Gimp-developer] Don't make an architectural mistake based on a groundless premise

[Øyvind Kolås <pippin gimp org>]

On Mon, Oct 6, 2014 at 6:57 PM, Elle Stone
<ellestone ninedegreesbelow com> wrote:
> On 10/05/2014 12:49 PM, Øyvind Kolås wrote:
> You've conceded that your architecture is broken to the point where you must
> hack in fixes for multiply. That's the first of many such hacks to come:

This is not the first such aspect of how pixel representation affects
computation that operation developers must take into consideration for
their operation (in which BablFormats they request). It is the same
type of choice already existing with regard to linear/perceptual as
well as pre-multiplied alpha or not, and should be dealt with in a
similar way.

I am going to try to describe the architecture of babl without
mentioning color.. instead of doing color computations we will pretend
to be doing temperature computations. Exactly how GEGL uses babl is
not relevant for the discussion.

Unfortunately enough - humans have many temperature scales, and they
use different temperature scales for different purposes. To facilitate
cooperation between scientists, engineers and others we have developed
a convention of tagging numbers we use to refer to temperature with a
unit qualifier, like thus: 37.7°C 100°F 310.9°K. That way, given a set
of conversions formulas, it is possible to operate in the preferred
unit. Some chemists need to do computations based on temperature
relative to the _local_ boiling point of water. To facilitate this one
can introduce a convention of local temperature; which could be 0.0 T
at 0.0 C and 100.0 T when water boils at current altitude, that would
might make these computations easier, this unit is the same as C some
places on earth and different elsewhere.

Being unchangeable units - like -  C, K and F is the purpose for
BablFormats existing, and the unit T is the proposed extension of our
vocabulary for these recipies/chemistry formulas/whatisit that works
differently at different heights.

I understand you to propose using T everywhere; (or a set of new Ts;
because in our case the differences between C and F are more important
than in the real world, and mean alpha/linearity/precision). Or that
interfaces at the edges of our system that are using C and F and
working well with it should be discarded or reimplemented - because C
and F will no longer mean what they meant when these systems were
established.

/pippin