[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-16 20:25:45
Message-ID: gap4o9$nj1$1 () ger ! gmane ! org
[Download RAW message or body]

Cyrille Berger wrote:
> On Monday 15 September 2008, Matthew Woehlke wrote:
>> IIRC, a while back I'd talked about a way to transfer a color channel to
>> an alpha channel via a node (i.e. such that it dynamically updates).
> 
> A filter could do that, the alpha channel (and obviously other the other 
> channels) are available when filtering. That's basically what the Color To 
> Alpha filter does.

Oh, do we have that already? I guess I haven't gotten krita to stay 
running long enough to poke around :-). (So can it perform an implicit 
colorspace conversion, so I can e.g. copy the Luma channel to Alpha from 
a layer that's RGB?)

>> I'd 
>> like to restate a desire for this, and also a way to create a
>> single-channel layer from another layer via colorspace conversion (i.e.
>> extract the effective "K" of CMYK from an RGB layer, etc.).
> A filter sounds also the correct solution.

Filter, whatever; the terminology/technology isn't a big concern as long 
as I can do it ;-).

>> As I recall this was in connection with generator layers (which possibly
>> produce exactly a float-16/32 gray channel) to be able to get alpha
>> layers out of them, but I realized they are useful for HDR photography
>> workflow.
> 
> Sorry I don't understand what you mean by that.

I mean that I think I decided many of the generators should produce 
grayscale output in a high-precision format; the idea being you'd apply 
color either via a solid-color generator with appropriate blend mode (if 
you only want a single color) or a gradient map, rather than build those 
options into umpteen generators. (Unless that can be done without 
unfortunate code duplication...)

>> Specifically, I want to be able to do this:
>>
>> -Start with two exposures of a raw*, 'e1' and 'e2'.
> For 2.0 (at least), the raw would have to be converted to one of the HDR float 
> color space.

Well, obviously :-). Ability to import raw directly, with no processing 
except de-bayering and data-normalization (i.e. converting from the 
sensor's 12- or 14-bit to fp32) is preferred, but as I mentioned, I 
could also convert them to 16-bit TIF in rawstudio. (Of course, I'll get 
a better result with direct-import because it will preserve the HDR 
information for later blending; a major plus!) But it seems like last 
time I tried to load a .nef, Krita crashed and burned.

Krita is part of the beta, yes? If so, I'll raise my expectations and 
start filing bugs rather than assuming "it's not ready yet" like I've 
been doing.

When you say "for 2.0", what other options would there be? Is de-bayer 
really finicky enough that we need to preserve the original bayer'd data 
and allow the de-bayer algorithm to be tweaked like any other filter layer?

>> Bonus points if Krita can do everything rawstudio can... which I *think*
>> it can, except it seems raw import wasn't stable last I tried,
> /me looks around for the bugs reports ;) I only tried with nef and it works 
> fine for me.

Curious, I'll try to look again as soon as I get a chance, but IIRC it 
wasn't working last I tried. (I have a D300, so, also .nef.)

Hmm... I wonder if it's getting bit by a dcraw bug. I'm using a hacked 
rawstudio b/c it would overrun the dcraw buffer by 8 bytes, which a: 
made importing the camera white balance not work, and b: destroyed the 
heap causing it to crash as soon as I tried to load a second image. I'm 
suspicious that this is actually a dcraw bug (making the buffer 16 bytes 
larger fixed it for rawstudio), and so I wonder if dcraw is misreporting 
the data size, which might be killing krita as well.

>> Quadruple bonus points if it can import the .xml's from rawstudio :-D.)
> I fear we are going to fail on that ;) (unless someone offers a patch ;) )

I may work on it. There isn't a huge amount of data to translate (in 
fact, everything but the curve is essentially trivial), and it's 
probably easier (and quicker) for me to do initial tone mapping in 
rawstudio and then import it, especially when I'm probably not doing 
krita-level post-processing on the majority of my pictures. IOW I think 
that having this ability will be very useful to me.

I'd like to get digikam to where it can both manage albums AND do the 
processing work I currently do in rawstudio. Right now digikam doesn't 
seem to work, period (I can't get it to show any pictures, ever, so I 
don't even know what it does).

-- 
Matthew
There's no place like ~. -- Unknown

_______________________________________________
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]