On 2011-03-31 19:07, Niko Kiirala wrote:
Thu, 31 Mar 2011 10:04:43 -0600 Jason Creighton <jcreigh@...400...> kirjoitti:
... This would seem to require that each bitmap in the filtering chain gets tagged with what its colorspace is, with conversions being done as needed before each filter primitive is applied. Hopefully the common case would be either sRGB or linearRGB being used in the entire filter, but we'd have to support the general case.
Is that basically right?
Seems correct, yes. Implementing the color-interpolation-filters would probably include extending src/display/nr-filter-slot.{cpp,h} which does somewhat similar bitmap conversions already (though for orientation, not colour spaces).
I'd like to note that there are actually two color-interpolation properties, one that applies to filters and one that applies to everything else (including things like gradients), so in the end both would need to be supported. However, for a GSoC project I would indeed definitely start with the one for filters, as that's where the main problem lies (someone apparently thought it would be nice to make the default for filters different from the rest).
For good results even more work may be needed than it seems. As it stands, filter primitives operate on ordinary 8-bits-per-channel RGBA images. Converting such image from sRGB to linear, filtering and converting back to sRGB will lose quite a bit of colour information. This could result in things like banding. The fix would be to use higher colour depth for the intermediate images (there are other reasons to do this, too).
There are definitely more reasons to do that, and it would be great to see something done about it, but I agree that this need not be connected to solving the sRGB vs. linearRGB issue.
Just a note so you'll know what to expect. It's totally not meant to say that your plan for GSOC needs to include fix for this problem.