Sure, I think that would be a Good Thing to do (wrapping your various color
transformations into a PDL::Transform::Color package that just exports a bunch
of PDL::Transform constructors). Among other things, that would mean you could
implement outlying ones simply, by composing the other transforms together
(e.g. you get HSV<->CMYK for free if you've written HSV<->RGB and CMYK<->RGB).
The only filip is that the ::Color transform routines should probably all
include some breakage of the standard threading rule, by looking for active
dimensions *after* the 0 dim. That is, for many applications images are
stacked up as <w>x<h>x3-PDLs rather than as 3x<w>x<h> PDLs. Since the color
index dim is the active dim, that implies doing a lot of things like:
$im2 = $im1->mv(2,0)->apply(t_rgb2hsv)->mv(0,2);
which is awkward.
But essentially all images have dimensions bigger than 4x4, so t_rgb2hsv could
go looking for any dim of size 3 or 4 (so that it could handle rgba images) in
the first three dims of the input. That is not a big deal to implement, nor is
it particularly expensive...
On Jan 11, 2012, at 12:37 PM, David Mertens wrote:
> Craig -
>
> After a closer inspection of PDL::Transform and a refresher on my code, I
> don't think it would be good to implement this using PDL::Transform. Wrapping
> the conversion into a transform would make sense, but not implementing it as
> a PDL::Transform. HSV -> RGB involves a very confusing six-way branch with
> calculations from derived values. I only vaguely understand the logic myself;
> it's based on a writeup I read on wikipedia. You could do this using PDL, but
> the calculation that would either involve Perl-level loops or be awkwardly
> and inefficiently represented with conditional expressions like this:
>
> my $result = ($a < $b) * ($a * 360) + ($a > $b) * ($b * 360);
>
> The conditionals and calculations would be even more complicated that what's
> shown here. That's an awful lot of temporaries, and five of every six
> calculations would be thrown away. However, it *would* make sense to wrap the
> current RGB->HSV in a transform, so that it could be easily composed with
> other transforms.
>
> David
>
> On Wed, Jan 11, 2012 at 10:50 AM, David Mertens <[email protected]>
> wrote:
> Hmmm, perhaps I should finally read the docs on PDL::Transform. There are
> *so* many parts of PDL about which I know little to nothing.
>
>
> On Wed, Jan 11, 2012 at 10:46 AM, Craig DeForest <[email protected]>
> wrote:
> This type of conversion is a natch for a PDL::Transform subclass...
>
>
> On Jan 11, 2012, at 9:20 AM, Maggie X wrote:
>
>> Sure, I can add them. Not sure I have committer status though :) Haven't
>> worked on PDL proper yet.
>>
>> Maggie
>>
>> On Wed, Jan 11, 2012 at 11:06 AM, David Mertens <[email protected]>
>> wrote:
>> Maggie -
>>
>>
>> On Tue, Jan 10, 2012 at 9:42 PM, Maggie X <[email protected]> wrote:
>> Hi David,
>>
>> Your code converts between HSV and RGB. But it's not that different to
>> convert between HSL and RGB.
>>
>> Oh, sorry! All these nearly-identical acronyms get me confused.
>>
>> Chris suggested that I add the HSL and RGB conversion to PDL::ImageRGB. What
>> do you think of putting the HSV and RGB conversion in PDL::ImageRGB?
>>
>> Having these generally available makes a lot of sense to me. Do you want to
>> add them, or shall I?
>>
>> Best,
>> Maggie
>>
>> Regards,
>> David
>>
>> _______________________________________________
>> Perldl mailing list
>> [email protected]
>> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
>
>
>
>
> --
> Sent via my carrier pigeon.
>
>
>
> --
> Sent via my carrier pigeon.
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
