Wanted: channel remapping with implicit colorspace conversion

Matthew Woehlke mw_triad at users.sourceforge.net
Thu Sep 18 20:01:57 CEST 2008


Cyrille Berger wrote:
> On Thursday 18 September 2008, Matthew Woehlke wrote:
>> 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.
> 
> Yup, but debayerisation + wb is about the only filters we can creates 
> automatically on import of raw files.

Right. To clarify, I meant that we'd either keep the existing dialog and 
use it as a "wizard" to create additional filters doing the same 
operations that are currently "baked", or else we would indeed only 
create debayer + wb. Either would be OK with me, though I lean a bit 
toward "wizard" mode.

>> (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?)
> Yes the code is available (and isn't complicated for that matter) but no it's 
> not wrappable, libkdcraw only give the resulting image (and that's all it can 
> give access cucrrently)

Ok, I guess libkdcraw needs work then :-). (Ah... *dcraw* can provide 
the raw, pre-bayer data, right? And libkdcraw is a dcraw wrapper, yes?)

-- 
Matthew
ENOCOFFEE: operator suffering from lack of sleep and/or early-morning-itis



More information about the kimageshop mailing list