Chris - Fascinating idea! That would be amazing! It would be PDL DWIM taken to a whole new level. Here are my thoughts, in a semi-coherent fashion:
In order to get this to work, we would have to modify the way that PDL::PP processes the inputs. We might be able to get this working in Perl-side code (or XS code if somebody has the brains and tuits) which would use affine slices to 'line-up' the dimension lists before calling the threading engine. IN FACT, we could even have the dimension names from the Pars key be the expected names of the dimensions. Of course, this would raise issues such as aliasing names (should a Fourier transform call its expected single dim 'time' or 't_series', and if so, what if you were taking the Fourier transform that had some other dimension. If there are output piddles, the names of the resulting piddles' dimensions would be the names of the dimensions in the order specified in the Pars section. On Wed, Jan 11, 2012 at 3:05 PM, Chris Marshall <[email protected]>wrote: > I think it may be time to consider adding support > for some sort of tag or ID for dimensions as an > alternative to strict order in the dims list. > > If you read in an image, then the IO routine could > "tag" the dimensions with qw( rgba x y ) to indicate > that dim0 is the color dimension, x is the horizontal > pixel dimension, and y is the vertical pixel dimension. > This allows for more generic interfaces than we > currently have. One could even include default > propagation options for various routines on those > objects. > > --Chris > > On Wed, Jan 11, 2012 at 3:54 PM, Craig DeForest > <[email protected]> wrote: > > 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 > > > > _______________________________________________ > Perldl mailing list > [email protected] > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl > -- Sent via my carrier pigeon.
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
