From kde-kimageshop  Wed Sep 17 23:08:09 2008
From: Matthew Woehlke <mw_triad () users ! sourceforge ! net>
Date: Wed, 17 Sep 2008 23:08:09 +0000
To: kde-kimageshop
Subject: Re: Wanted: channel remapping with implicit colorspace conversion
Message-Id: <gas2kq$r68$1 () ger ! gmane ! org>
X-MARC-Message: https://marc.info/?l=kde-kimageshop&m=122169295129873

Cyrille Berger wrote:
> On Wednesday 17 September 2008, Matthew Woehlke wrote:
>> Ok, you made me try it. Seems to have worked this time; but I'd (not
>> surprisingly ;-) ) prefer to be able to fiddle with the white balance
>> after, rather than having to pick something at import. (I guess we do
>> want to be able to read in the camera white balance, but could the
>> import dump the de-bayered data without other processing onto one layer
>> and create filter layers for the rest?)
> 
> The import does that, since it's stored in the metadata.

Right, that's what I was getting at. But it would be awesome if the 
import would create filter layers for this stuff so it can be tweaked 
afterward.

So, taking into account your thoughts on bayer, I think what would be 
ideal (including further-future work) is for import to create a stack 
like this:

Curves filter (no CS change)
Hue/Saturation filter (no CS change)
White Balance filter (no CS change)
Curves filter (no CS change)
De-bayer filter (to i/fp 16/32 CS)
Totally unprocessed RAW data. (bayer CS)

...and filters just "wouldn't work" on bayer CS (maybe some would but I 
don't think we need to go out of our way to make *any* work).

Alternatively... does de-bayer take four input pixels for one output 
pixel (i.e. the input is 2x the resolution of the output), or is there 
interpolation going on as well? If the latter, we could just implement 
de-bayer as a filter, and simply dump the bayer data as raw i16 data 
(probably as gray rather than rgb, to save space). Filters would be very 
strange if you tried to use them on non-de-bayer'd data (for that 
matter, looking at the image would be pretty strange), but everything 
would "work".

> But we don't have a white balance filter.

We don't? ;-)
Actually, white balance (a.k.a. tint/warmth) is a filter IMHO we really 
/ought/ to have... I guess it's getting too late to add this in 2.0?

(Although, does krita do the w.b. or does [libk]dcraw handle it? If the 
latter, doesn't that mean the code is already available, and just needs 
to be wrapped in a filter?)

>>> Meanwhile, I should probably still ask: would you find it useful to have
>>> additional test .nef's with different encodings? (Or is that from
>>> dcraw?) Even if there is no krita bug, I imagine that supplementing the
>>> collection of test formats wouldn't hurt.
>> This of course is still open.
> 
> Well I guess it doesn't hurts. But due to the size it won't be possible to 
> have them in the official test suite ;) 

Aww, they're "only" 12-15 M ;-). (Actually, since I'd likely use a white 
wall for a test shot, possibly smaller.)

Is the uncompressed one just one you have, then? And where/how should I 
send them?

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

_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop