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 _______________________________________________ gegl-developer-list mailing list List address: gegl-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
