On Mon, Apr 20, 2015 at 02:31:00PM +0200, Krzysztof Kosiński wrote:
2015-04-20 7:04 GMT+02:00 Gez <listas@...3059...>:
It would be a huge benefit for artists if all the compositing and color blending was done in linear RGB, then gamma-correct. Unfortunately, as you just pointed out, 8bpc is inadequate. The first time I saw the property in SVG that Tav mentions, it called my attention. It looked like somebody finally wanted to move away from the legacy 8bpc compositing in sRGB gamma and do the right thing, but I couldn't find more information about it. Is there some consensus about switching to linear compositing for the web? That would be great. And if that's the case. What's the stance of inkscape developers about it? Have you ever discussed about that possibility? Moving to higher bit depth would not only allow linear compositing, but also better gradients (there is at least one long standing bug report about banding in gradients), among other things.
Speaking for myself - I would immediately move to linear compositing, but the problem is that most of the compositing is actually done in external libraries (Cairo, Pixman) that don't have support for anything other than 8bpp sRGB color formats.
There are basically two possible paths to get linear RGB compositing: a) Add 16bpp formats to Pixman and Cairo. b) Port Inkscape to a rendering library that does support higher bit depths, such as GEGL.
a) requires things which are partially beyond our control, while b) is a very big project.
Given that one of us is one of the Cairo maintainers and can review and land our patches, this is actually very much within our control. Pixman changes may be a bit harder to land.
Honestly, both would be pretty non-trivial efforts. In the second, it's a lot of work internal to Inkscape, but the first one the effort is in Cairo/Pixman: Support for the data type would need added throughout the codebase, documentation updated, and test cases updated to use the new pixel type. On the plus side, Cairo already supports an array of pixel color formats so most of the places it needs added are already case statements.
One color type was already added recently - it landed right before I got involved, and a lot of my early patch review work was fixing fallout from that. However that was "just" another 8bpc format; 16bpc formats will likely have much bigger impacts, such as having to change certain data fields from 32-bit ints to 64-bit. If this impacts the cairo API (as it assuredly would), then things really get challenging; worst case might be having to establish a lot of new API just to get the datatypes upgraded...
Anyway, option (a) isn't beyond our control. It *would* be a lot of work. On the plus side, it stands to benefit the whole community (at least, those using cairo) so the concern about transitioning SVG viewers and browsers and other tools may be lessened by that.
Bryce