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