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

[Elle Stone <ellestone ninedegreesbelow com>]

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":

Png is a fully color-managed file format, supporting images in any and 
all color spaces. The sRGB png chunk is specifically for use with pngs 
that are already in the sRGB color space, for cases when the artist 
doesn't want to embed an actual sRGB ICC profile.

Jpeg is a fully color-managed file format. There is no requirement that 
a jpeg be in the sRGB color space. Many digital cameras allow saving 
in-camera jpegs in the AdobeRGB1998 color space. The internet is full of 
jpegs that are in color spaces other than sRGB.

If GTK has built into the code any requirement that GTK-based image 
editors can only be used to edit images that are encoded using the sRGB 
primaries (doubtful), then GTK is broken, in which case file a GTK bug 
report or replace GTK with a library that isn't broken.

v4l adds support for webcams, tv tuners, etc to the linux kernel. If v4l 
is hard-coded to use BT.709 primaries in a world where video is rapidly 
moving to wide gamut devices, file a bug report.

ffmpeg handles multimedia codecs, for which BT.709 is the past, not the 
future. See this request for adding Rec.2020 support to ffmpeg: 
https://trac.ffmpeg.org/ticket/2382

At best, v4l and ffmpeg make a case for including device-specific 
editing functions to handle device-specific cases. These few editing 
functions should be prominently labelled as such in the code and in the UI.

Elle