Linear RGB and Mesh Gradient
Hi, a question is posibol use Linear RGB in Mesh Gradients to avoid dark holes? Can be a GUI option? Maybe PDF/AI compatibility problems?
Regards, Jabier.
On Fri, 2015-04-17 at 14:49 +0200, Jabier Arraiza wrote:
Hi, a question is posibol use Linear RGB in Mesh Gradients to avoid dark holes? Can be a GUI option? Maybe PDF/AI compatibility problems?
It would be nice to be able to use Linear RGB everywhere. There is a property in SVG to dictate that blending etc. should be done in the linear RGB space but it is not supported by anyone that I know of. I looked awhile back at implementing it in SVG when I implemented linear RGB support for filters but it didn't seem to be easy to do.
Tav
Thanks for the info Tav.
On Fri, 2015-04-17 at 15:37 +0200, Tavmjong Bah wrote:
On Fri, 2015-04-17 at 14:49 +0200, Jabier Arraiza wrote:
Hi, a question is posibol use Linear RGB in Mesh Gradients to avoid dark holes? Can be a GUI option? Maybe PDF/AI compatibility problems?
It would be nice to be able to use Linear RGB everywhere. There is a property in SVG to dictate that blending etc. should be done in the linear RGB space but it is not supported by anyone that I know of. I looked awhile back at implementing it in SVG when I implemented linear RGB support for filters but it didn't seem to be easy to do.
Tav
On 04/17/2015 03:37 PM, Tavmjong Bah wrote:
On Fri, 2015-04-17 at 14:49 +0200, Jabier Arraiza wrote:
Hi, a question is posibol use Linear RGB in Mesh Gradients to avoid dark holes? Can be a GUI option? Maybe PDF/AI compatibility problems?
It would be nice to be able to use Linear RGB everywhere. There is a property in SVG to dictate that blending etc. should be done in the linear RGB space but it is not supported by anyone that I know of. I looked awhile back at implementing it in SVG when I implemented linear RGB support for filters but it didn't seem to be easy to do.
This is indeed a shame, but in principle it's possible to use a work-around by converting the colours used in the mesh to linearRGB manually, and then applying a filter over the output that goes back to sRGB (at least approximately, using feComponentTransfer). It's a bit dirty, and may not get the best possible image quality, but it might be good enough for some purposes at least.
2015-04-17 17:19 GMT+02:00 Jasper van de Gronde <th.v.d.gronde@...528...>:
On 04/17/2015 03:37 PM, Tavmjong Bah wrote:
On Fri, 2015-04-17 at 14:49 +0200, Jabier Arraiza wrote:
Hi, a question is posibol use Linear RGB in Mesh Gradients to avoid dark holes? Can be a GUI option? Maybe PDF/AI compatibility problems?
It would be nice to be able to use Linear RGB everywhere. There is a property in SVG to dictate that blending etc. should be done in the linear RGB space but it is not supported by anyone that I know of. I looked awhile back at implementing it in SVG when I implemented linear RGB support for filters but it didn't seem to be easy to do.
This is indeed a shame, but in principle it's possible to use a work-around by converting the colours used in the mesh to linearRGB manually, and then applying a filter over the output that goes back to sRGB (at least approximately, using feComponentTransfer). It's a bit dirty, and may not get the best possible image quality, but it might be good enough for some purposes at least.
8 bits is simply not enough for linear RGB compositing. IIRC, the 256 distinct linear RGB values that can be represented with 8 bits per component are converted to less than 100 distinct color values in sRGB, which results in completely unacceptable image quality and visible banding. At least 16 bits per component are needed for reasonable quality in linear RGB, and 16-bit floats (aka "half floats") are optimal.
Regards, Krzysztof
El vie, 17-04-2015 a las 19:39 +0200, Krzysztof Kosiński escribió:
8 bits is simply not enough for linear RGB compositing. IIRC, the 256 distinct linear RGB values that can be represented with 8 bits per component are converted to less than 100 distinct color values in sRGB, which results in completely unacceptable image quality and visible banding. At least 16 bits per component are needed for reasonable quality in linear RGB, and 16-bit floats (aka "half floats") are optimal.
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.
The transition seems complicated, though. If inkscape moves to linear compositing, then browsers and SVG viewers should move to linear compositing as well, otherwise there would be mismatches in the rendering appearance.
Gez
It's a long lasting problem in SVG filter effects color transitions and blur smoothness too. It causes visible banding imperfections for example in Bevel filters and prevent to use them in many cases. And there are no true workarounds.
Of course in filters compositing too it's a big problem.
I discussed it a bit a very long time ago with Bulia Byak and others when I began to design filters. But the SVG state at this time didn't permit to solve that and that was very discouraging.
I hope so much that will be solved one day !
ivan
------------------------------------------------------------------------
Le 20/04/15 07:04, Gez a écrit :
El vie, 17-04-2015 a las 19:39 +0200, Krzysztof Kosiński escribió:
8 bits is simply not enough for linear RGB compositing. IIRC, the 256 distinct linear RGB values that can be represented with 8 bits per component are converted to less than 100 distinct color values in sRGB, which results in completely unacceptable image quality and visible banding. At least 16 bits per component are needed for reasonable quality in linear RGB, and 16-bit floats (aka "half floats") are optimal.
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.
The transition seems complicated, though. If inkscape moves to linear compositing, then browsers and SVG viewers should move to linear compositing as well, otherwise there would be mismatches in the rendering appearance.
Gez
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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. For example, GEGL doesn't do SVG-compliant stroking, so we would first need to write an SVG-compliant path stroker. (There is some work on this already, but AFAICT it doesn't support dashing.)
I think going the b) route will be more beneficial in the long run. Ideally we should support multiple pluggable renderers.
The transition seems complicated, though. If inkscape moves to linear compositing, then browsers and SVG viewers should move to linear compositing as well, otherwise there would be mismatches in the rendering appearance.
Fortunately SVG has the CSS properties color-interpolation and color-interpolation-filters that allow you to specify what you want. Almost no-one supports them yet, but the migration path is already laid out.
Regards, Krzysztof
On Mon, 2015-04-20 at 14:31 +0200, Krzysztof Kosiński wrote:
Fortunately SVG has the CSS properties color-interpolation and color-interpolation-filters that allow you to specify what you want. Almost no-one supports them yet, but the migration path is already laid out.
Small correction: Almost everybody, including Inkscape, supports color-interpolation-filters as its default value is linearRGB.
Tav
2015-04-20 17:22 GMT+02:00 Tavmjong Bah <tavmjong@...8...>:
On Mon, 2015-04-20 at 14:31 +0200, Krzysztof Kosiński wrote:
Fortunately SVG has the CSS properties color-interpolation and color-interpolation-filters that allow you to specify what you want. Almost no-one supports them yet, but the migration path is already laid out.
Small correction: Almost everybody, including Inkscape, supports color-interpolation-filters as its default value is linearRGB.
But do we actually compute filters in linear RGB when that property is set to 'linearRGB'?
I know that all filter code relies on Cairo and is 8bpp, so we either do linear RGB filters poorly or not at all.
Regards, Krzysztof
On Mon, 2015-04-20 at 18:12 +0200, Krzysztof Kosiński wrote:
2015-04-20 17:22 GMT+02:00 Tavmjong Bah <tavmjong@...8...>:
On Mon, 2015-04-20 at 14:31 +0200, Krzysztof Kosiński wrote:
Fortunately SVG has the CSS properties color-interpolation and color-interpolation-filters that allow you to specify what you want. Almost no-one supports them yet, but the migration path is already laid out.
Small correction: Almost everybody, including Inkscape, supports color-interpolation-filters as its default value is linearRGB.
But do we actually compute filters in linear RGB when that property is set to 'linearRGB'?
I know that all filter code relies on Cairo and is 8bpp, so we either do linear RGB filters poorly or not at all.
At each step of the filter chain, the Cairo surface is marked as sRGB or linearRGB via a user data flag. Conversion between sRGB and linearRGB is done as needed. (See ink_cairo_surface_linear_to_srgb()) The end result of the filter chain is then converted to sRGB if necessary. Conversion is done with eight bits per color so it is not ideal but for most filters it seems to be adequate. We can do this for filters as they are always written out as bitmaps when exporting. Doing this for vector objects is more problematic.
Tav
2015-04-20 20:14 GMT+02:00 Tavmjong Bah <tavmjong@...8...>:
At each step of the filter chain, the Cairo surface is marked as sRGB or linearRGB via a user data flag. Conversion between sRGB and linearRGB is done as needed. (See ink_cairo_surface_linear_to_srgb()) The end result of the filter chain is then converted to sRGB if necessary. Conversion is done with eight bits per color so it is not ideal but for most filters it seems to be adequate. We can do this for filters as they are always written out as bitmaps when exporting. Doing this for vector objects is more problematic.
OK, I remember now.
The current approach should look adequate in filters.svg because it normally has a white background. The quality problems are only noticeable in dark areas. See attached image. Generating program also attached, compile with:
gcc srgb-roundtrip.c `pkg-config --cflags --libs cairo` -lm -o srgb-roundtrip
This can't be easily fixed without a new 16bpp pixel format in Cairo (which will require a whole new 16bpp compositing pipeline) or using a different renderer, so I don't think we can do anything about this for now.
Regards, Krzysztof
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
participants (7)
-
Bryce Harrington -
Gez -
ivan louette -
Jabier Arraiza -
Jasper van de Gronde -
Krzysztof Kosiński -
Tavmjong Bah