On Wed, Oct 8, 2014 at 3:25 PM, Elle Stone
<ellestone@xxxxxxxxxxxxxxxxxxxx> wrote:
> On 10/07/2014 08:23 PM, Øyvind Kolås wrote:
>> The choice of something "close" to sRGB is to have efficient
>> integration with libpng/libjpeg/gtk/v4l/ffmpeg (in addition to raster
>> layers stored in sRGB).
>
> None of the above-listed libraries justify using a broken architecture that
> requires converting images to "sRGB as PCS":
You're not supposed to have to care about the PCS of a color management system.
So I don't see how "sRGB as PCS" can broken, however enforcing linear
sRGB, which is babls PCS, as a working space is something we have
acknowledge to be broken in our color management architecture ever
since we started talking about having support for "target" /
"chromaticity" spaces.
linear sRGB being used as the PCS should have no bearing on which
other formats are supported. Since the theoretical - albeit due to
optimizations not true - computational path is source format -> PCS ->
destination format. Redefining what "RGBA float" means destroys the
ability for the babl_model("RGBA") to act as a PCS at all, this is
where "RGBA double" is the Celcius from the temperature analogy. It is
perhaps unfortunate that the name of the PCS as exposed in the API is
"RGBA double/float..", and that the way the vocabulary has been
defined that "R'G'B' u8" the non-linear variant of the PCS directly is
sRGB, but this has allowed the existing code to be consistently
written and be certain that both color management, data types and
opacity and are in the expected format (not only color-space) at all
times.
The type of BablFormat which most closely resembles what is desired to
break free of sRGB with babl, is the babl-palette type formats which
implement indexed mode in GIMP. Where the per palette BablModels fuel
per palette BablFormats, providing a crude-non-dithering transparent
conversion to and from RGBA permitting GEGL operations to work on this
pixelformat transparently. The important part being the use of
BablModel's with allocated data containing the palette. This despite
the naming in the existing code leading you to think otherwise.
The way palette formats are addressed would not be suitable for RGB
profiles and for instance the use of them for linear processing on
chromaticity dependent operations, hence the "target:RGB float" prefix
I used in another e-mail for the format.
On the public API of babl we then need an additional call to specify
what "target" or "camera2-chromaticities" or some other named RGB
format is.
void babl_set_named_rgb_chromaticities (
Babl *babl,
const char *name,
double red_xyz[3],
double blue_xyz[3],
double green_xyz[3],
int white_reference);
At this stage; we would be able to control which formats are being
used inside a GeglOperation, we could even add utility functions which
derive the working-space for the current operation based on
combinations of parameters from the op-author, and the environment
(GIMP); permitting to implement various flows of data. And at some
point start referring to sRGB with a different babl format.
Making it possible to have concurrent views; in separate open
documents is something made harder by naming the model in the format
name; that the existing palette api solves. This can be catered for by
permitting to create sub-Babl *babl instances with their own
namespaces and formats - where all babl formats derived from the same
root Babl * are possible to use with each other.
/Ø
_______________________________________________
gimp-developer-list mailing list
List address: gimp-developer-list@xxxxxxxxx
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list
