[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    Re: Wanted: channel remapping with implicit colorspace conversion
From:       Matthew Woehlke <mw_triad () users ! sourceforge ! net>
Date:       2008-09-18 18:08:06
Message-ID: gau5e6$l38$1 () ger ! gmane ! org
[Download RAW message or body]

Cyrille Berger wrote:
> On Thursday 18 September 2008, Matthew Woehlke wrote:
>>> 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".
>> ...how about it? This would even have the advantage that it works *now*
>> (assuming convolution-like filters work, anyway! i.e. someone figured
>> out how to run filters against tiles when they need neighboring pixels),
>> and would be 100% preserving.
> 
> Tiles are hidden in Krita. You don't see them, and don't have to care about 
> them. (and yes we have convolution-like filters for quiet some times now)

...but the filters need to know about them, yes? (At least, enough to 
say "and btw, I need X surrounding pixels to work"?)

What did you think of importing bayer'd data as i16 gray? Good idea? Bad 
idea? Do you think that would work, to import bayer as 1-channel with 
high bit depth, have a de-bayer filter (with possibly fp32 output), and 
then stack w.b., curves, etc filters on top of that? That should provide 
total data preservation* from raw sensor data through everything done to 
get the final image.

(* except for metadata, though I imagine we could copy that also, yes?)

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

_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]