Wanted: channel remapping with implicit colorspace conversion

[Cyrille Berger]

On Thursday 18 September 2008, Matthew Woehlke wrote:
> > Tiles are hidden in Krita. You don't see them, and don't have to care
> > about them. (and yes we have convolution-like filters for quiet some
> > times now)
>
> ...but the filters need to know about them, yes? (At least, enough to
> say "and btw, I need X surrounding pixels to work"?)
No. Who told you we were using tiles to store images ? The point is the filter 
doens't have to care or to know. That said, we have a function in the filter 
that tell how much pixels the filter need around the working area. But that's 
not used by the data manager, but rather for mutlithreading purpose ;)

> What did you think of importing bayer'd data as i16 gray? Good idea? Bad
> idea?
Good idea up to a small detail. I don't think that filter that output to a 
different color space than the input color space works well currently. But 
that's implementation detail ;)

> Do you think that would work, to import bayer as 1-channel with 
> high bit depth, have a de-bayer filter (with possibly fp32 output), and
> then stack w.b., curves, etc filters on top of that? That should provide
> total data preservation* from raw sensor data through everything done to
> get the final image.
>
> (* except for metadata, though I imagine we could copy that also, yes?)
Metadata is stored inside the imported layer (that would be the one in 
grayscale). When flatening an image, we have different meta data merge 
strategy to create meta data for the resulting projection.

-- 
Cyrille Berger