From kde-kimageshop Tue Sep 16 20:25:45 2008 From: Matthew Woehlke Date: Tue, 16 Sep 2008 20:25:45 +0000 To: kde-kimageshop Subject: Re: Wanted: channel remapping with implicit colorspace conversion Message-Id: X-MARC-Message: https://marc.info/?l=kde-kimageshop&m=122159681101319 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