Re: [Gegl-developer] [Gimp-developer] Don't make an architectural mistake based on a groundless premise
- From: Øyvind Kolås <pippin gimp org>
- To: Elle Stone <ellestone ninedegreesbelow com>
- Cc: gegl-developer-list <gegl-developer-list gnome org>, Simone Karin Lehmann <simone lisanet de>, "gimp-developer-list gnome org" <gimp-developer-list gnome org>
- Subject: Re: [Gegl-developer] [Gimp-developer] Don't make an architectural mistake based on a groundless premise
- Date: Tue, 7 Oct 2014 20:57:10 +0200
On Tue, Oct 7, 2014 at 8:10 PM, Elle Stone
<ellestone ninedegreesbelow com> wrote:
I'm posting to the original thread. Pippin had started a new thread:
https://mail.gnome.org/archives/gimp-developer-list/2014-
gmail started a new thread when I tired to change the alarmist subject.
Brasseur shows why scaling needs to be done on linearized RGB. The defining
primaries are irrelevant. Nothing in Brasseur's demonstrations provide any
justification for a forced conversion to "sRGB as PCS".
They provide a justification for keeping track of the pixel format of
the buffers, or enforcing that only linear spaces are permitted
processing spaces. There in practice with regard to data loss, no
forced conversion to sRGB. Any more than any use of ICC profiles would
be a forced conversion to CIE XYZ.
Babl provides the vocabulary and set of _defined_
units to be able deal with the multitude of temperature units/pixel
formats in use by different algorithms and libraries.
I do understand how babl/GEGL works. There is a difference between
"understanding" and "agreeing".
To me it seems like you do not like the fact that the neutrally
sounding babl_format name "RGBA float" is strictly defined in the
architecture of both babl and GEGL, and see this as the thing in the
architecture that should be changed to be *the*processing*space*.
While I am arguing that this is existing functionality we need; and
that reconfigurable primaries should be a separate addition instead of
deleting both neccesary functionality and optimizations for common
pixel formats.
Any architecture that requires hacks to make basic editing operations work
is broken. You can dress it up and make it sound like the hacks are just
extending existing functionality. But in this case it's obvious that the
reason for the hacks is to fix something that is only broken because of an
architecture that intends to use "sRGB as PCS".
Since April I've tried to explain why Pippin's architecture is broken. I've
used logic, examples, equations, pictures, long explanations, short
explanations, and other people's explanations.
I have not disagreed that the current architecture is broken, but what
you call hacks is how GIMP-2.9 avoids gamma errors when blurring and
scaling, regardless of wheter you are editing an 8bit image with its
layers stored non-linearly or not; as well as other distinctions where
different operations have the need to do processing with different
pixel representations.
/Ø
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]