On 10/10/2014 07:49 PM, Øyvind Kolås wrote:
On Sat, Oct 11, 2014 at 1:18 AM, Elle Stone
<ellestone@xxxxxxxxxxxxxxxxxxxx> wrote:
So I have two specific questions. The first question is about
converting to LAB. The second question (which I haven't asked yet) has to do
with Y.
We will try to do what makes sense and helps us achieve what we need
to achieve efficiently; while keeping what works well, working well.
The above statement is devoid of content. It serves to dismiss my
specific questions about why you want to keep hard-coded sRGB XYZ and Y
in a color-managed workflow.
"sRGB as PCS" is linear gamma unbounded sRGB. I think it's reasonable to ask
why a conversion to unbounded sRGB should be involved in a conversion from
User_RGB to LAB.
For the same reason XYZ is involved (or not, depending on how the CMM
does it) in an ICC workflow.
Please provide a specific example of an actual CMM in an ICC profile
workflow that doesn't use XYZ for converting between RGB working spaces.
Existing code written with assumptions of sRGB, whether in GIMP and
GEGL that we control or in XPM, GTK, GDK, or elsewhere that has sRGB
assumed will continue to work. We take the existing architecture which
is following general guidelines of assuming sRGB where none is
specified.
A guideline for dealing with images that don't have embedded ICC
profiles makes an appalling bad guideline for writing a color-managed
image editor.
This is not about how images with no embedded profile are handled.
sRGB derived 8bit (and to a lesser degree 16bit) formats are used for
many other things than images with no embedded profile.
You falsely assume that 8-bit images are always sRGB images and that
16-bit integer images are probably sRGB images.
These pixel
formats are crucical for integrating with existing file formats and
libraries;
File formats that only work with sRGB images should not impact
color-managed image editing. Advise the user to convert to sRGB.
Accurate UI colors is a desktop color management issue, entirely
irrelevant to programming a color-managed image editor.
and we want these conversions to be as fast as possible -
even if it might have an impact on the conversion speed for CIE Lab,
though that does not have to be the case either. Choosing any PCS
*but* linear sRGB into a PCS would tend to make these important
conversions slower.
Unbounded linear gamma sRGB is not a Profile Connection Space.
Idiosyncratic redefinitions of well-established color management terms
confuses people who don't understand ICC profile color management.
Idiosyncratic redefinitions of well-established color management terms
makes it difficult for people who do understand ICC profile color
management to communicate with the babl/GEGL devs.
I can move on to my question about Y and unbounded sRGB. But I still don't
understand why unbounded sRGB should be involved in a conversion from
User_RGB to LAB.
We will do what makes most sense and is neccesary when we get there, I
suspect each RGB model with have an associated Y and YA model. Due to
how the existing BablModels interact with components and vocabulary
used to address them in babl; potential support for different TRCs is
even vaguer; we'll know when we have more code.
Is there any point in my demonstrating how convoluted and unworkable it
will be to convert to unbounded sRGB whenever Y is involved? Because if
there isn't, I don't want to waste my time.
Maybe we have more code by the time of LGM, if not that would be an
excellent place to elaborate;
As I have indicated before, the invitation is very kind. But not
everyone is able to drop other obligations and go to LGM.
until then I prefer IRC.
Twice I tried to discuss problems with unbounded sRGB on IRC. It was
neither pleasant nor productive.
For a moment it seemed that perhaps unbounded sRGB was going to be
dropped and we could move on to generalizing the code to use Y and XYZ
taken from the user's chosen RGB working space
(http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html).
However, given Pippin's latest explanations of how things will be done,
I'm not sure there's any point in my continued involvement with GIMP
development.
Kindest regards,
Elle Stone
_______________________________________________
gegl-developer-list mailing list
List address: gegl-developer-list@xxxxxxxxx
List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
