Wanted: channel remapping with implicit colorspace conversion

[Cyrille Berger]

On Wednesday 17 September 2008, Matthew Woehlke wrote:
> Cyrille Berger wrote:
> >> [I]t seems like last
> >> time I tried to load a .nef, Krita crashed and burned.
> >
> > Well I just try, and it works fine.
>
> I'll try again. Did you test uncompressed, or lossless-compressed? (For
> obvious reasons, I only use the latter; I usually get a size savings of
> around 40-45%.)
Given the size of the file, it was uncompressed.

> > There is still some processing since there
> > is no good solution for now to load non-processing raw file.
> >  [re-arranging]
> > In Krita debayerisation is an other story, you can see my thoughts on the
> > subject in [1]. But, now I am not so sure that it is really a good idea.
> > For one thing, debayerisation is a linear process, and for an other,
> > quiet a few important operation need the full RGB triplet to be remotely
> > useful.
> >
> > [1] http://wiki.koffice.org/index.php?title=Krita/Direct_RAW_Editing
>
> Yes, I *seriously* doubt you would want to try to operate on bayer'd
> images. At "best", I'd treat it as a color space that must be converted
> before anything works, so you could a: save the exact raw data, and b:
> change the debayerisation algorithm, but everything would operate after
> conversion to a "normal" color space.

Well one advantage of applying color transformation on the bayer matrix is 
speed, since you would do color adjustement on three times less data.

> But I'm also unconvinced what the benefit would be. I'll stand by my
> question, how many knobs are there really to fiddle with in the
> debayerisation process? If there aren't many, or if the result of
> fiddling is negligible, then I don't see the benefit. (...And anyone
> that cares *that* much should know to not to delete the original raw.)
The results isn't negligible, there isn't one true answer to debayerisation. 
There are two algorithms which are usefull, one which works best for natural 
landscape, one which works better for artificial scenary.

> >> When you say "for 2.0", what other options would there be? Is de-bayer
> >> really finicky enough that we need to preserve the original bayer'd data
> >> and allow the de-bayer algorithm to be tweaked like any other filter
> >> layer?
> >
> > What I said is that there is no exposure filter, so the only way to
> > adjust exposure is through the overview filter which only work for HDR
> > color spaces.
>
> Other than being measured in E.V., is exposure really substantially
> different from brightness/contrast? It seems that Exposure+Contrast (as
> done by rawstudio) is just a simple 'Ax + B' mapping of the input data.
> So as long as you translate to a colorspace that doesn't lose precision
> too early in the pipe (I'm thinking, probably fp32), you should be able
> to emulate everything with curve mapping, no?
Yup. If you can make a curve that simulate a multiplication ;)

> The obvious complication is that you might need multiple passes; the
> controls in rawstudio might not be presented in the order they are
> appplied, but if  they  are, rawstudio does brightness, then saturation,
> then hue, then contrast, then curves.

The order of exposure/brightness/contrast/curves doesn't matter (if you 
preserve out of range data). But the order of Saturation/hue is important.

-- 
Cyrille Berger