From kde-kimageshop  Mon Sep 15 19:48:55 2008
From: Matthew Woehlke <mw_triad () users ! sourceforge ! net>
Date: Mon, 15 Sep 2008 19:48:55 +0000
To: kde-kimageshop
Subject: Wanted: channel remapping with implicit colorspace conversion
Message-Id: <game78$j4e$1 () ger ! gmane ! org>
X-MARC-Message: https://marc.info/?l=kde-kimageshop&m=122150822321470

(Please let me know if there's a particular spot on the wiki you'd like 
me to add this to.)

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). 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.).

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.

Specifically, I want to be able to do this:

-Start with two exposures of a raw*, 'e1' and 'e2'.
- Copy the luma channel (HCY, or maybe LAB, color space) from e2 to its 
own node.
- Create an alpha mask from that (bonus points for combining this with 
the previous step).
- Apply filter layers (blur, unsharp mask, and curves being the likely 
suspects, but any filters should be possible) to the mask.
- Combine the mask with a second mask layer which is hand-painted.
- Use the resulting mask to blend e2 onto e1.

(* Currently I'd be doing this via rawstudio and 16-bit TIF export. 
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, and 
possibly filter layers are still a bit flaky. Quadruple bonus points if 
it can import the .xml's from rawstudio :-D.)

I'm not asking to have this tomorrow :-). Just throwing out an idea I 
had before I forget it.

Further thinking: if filters can be made to apply to only the alpha 
channel (I think this is just generally needed?), and the conversion can 
overlay or otherwise apply the usual blending modes, then a simple 
channel remap with implicit conversion would suffice. IOW, this stack:

   blur*
   curves*
   conv(Y->A)
e2 [RGB]
e1 [RGB]

(* operating on A only)

...so conv, blur, curves are children of e2. All blend modes are 
'normal', so the conv replaces the A channel (except that there wasn't 
one, so "creates" would be better), becomes input to curves which 
replaces it again, becomes input to blur which replaces it again, and 
finally is used to blend that result (effectively, e2 plus the result A 
channel) with e1.

-- 
Matthew
"NT was a marketing name that stood for New Technology, but it was still 
an amusing coincidence that WNT was VMS with each letter replaced by the 
next one."
   -- Jeremy Reimer

_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop