Wanted: channel remapping with implicit colorspace conversion

[Matthew Woehlke]

Cyrille Berger wrote:
> 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.

Ok. I can't look until tonight, but methinks compressed might be the 
problem (wouldn't be surprising). Would it be useful for me to provide 
some sample .nef's? I can get you both 12- and 14-bit, with both lossy 
and lossless compression. (I only use 14-bit lossless, but someone else 
might want others of the above to work, and if you don't have them yet...)

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

Maybe. At any rate, I shouldn't try to talk you out of it if /you/ want 
to do it, just as long as you're not doing it only because you think I 
feel it's important :-).

>> 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.

Ok. I'm only familiar with whatever rawstudio uses, and can't say I've 
noticed any reason to complain.

Having everything from the raw to the final product in a completely 
non-lossy krita file would rock (less stuff to back up!), but certainly 
for now I think I'm ok with only having the de-bayer'd data in the krita 
file.

But I *do* want to have it where it contains the full de-bayer precision 
with the white balance / exposure / curves / everything as filter 
layers. It sounds like that won't be a problem, though :-).

>> 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 ;)

Um...? If I apply the brightness filter "2x + 0" (that performs a linear 
mapping 0->0, 128->255), isn't that simply a straight-line curve filter 
with those endpoints?

What am I missing?

A curve is merely an arbitrary function represented as a traditional 
graph (and usually specified as an interpolated curve). Therefore, any 
filter whose output is exactly one pixel for exactly one input pixel, 
with no other (non-constant) inputs, can be represented as a curve. It 
may have an inordinate number of points, but...

Unless I'm mis-guessing how they work, brightness/contrast and levels 
are both equivalent to simple curves (the former, a straight line, the 
latter a gamma curve, each with endpoints not necessarily at 0.0,0.0 and 
1.0,1.0).

>> 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).

...which HDR would do, and since this whole conversation started about 
HDR and I'm assuming we're talking about a non-normalized fp color 
space... :-)

(Well, technically it does matter since brightness/contrast changes the 
coordinate space for the curve. But if you're folding them all together, 
that becomes irrelevant. Even if you aren't, it just means you have to 
compensate for the order with appropriate transformation of the curve 
points.)

> But the order of Saturation/hue is important.

Right. But this of course is not a problem, it just means one has to 
actually pay attention to how rawstudio does it, so that we'd do it in 
the same order.

So in summary, it sounds like we'd be in good shape, and the hard part 
is more converting the parameters from rawstudio's xml into an 
equivalent filter stack.

-- 
Matthew
Your eyes are weary from staring at the CRT. You feel sleepy. Notice how 
restful it is to watch the cursor blink. Close your eyes. The opinions 
stated above are yours. You cannot imagine why you ever felt otherwise.
   -- Unknown
(found at http://goldmark.org/jeff/stupid-disclaimers/fun.html)