Thanks for pointing out PIIU, Derek.
As the author, I must apologize that PIIU is woefully out of date --
it still works, for what it is, but I have been meaning for years(!)
to add some how-to sections to it.
For image processing, things you'll want to think about (off the top
of my head) are:
IO:
rim/wim - threading image reader/writer that uses file extensions to
decide image type
PDL::Graphics::PLplot - newer, supported (but still a little rough
around the edges) PLPlot graphics output for figures and such
PDL::Graphics::PGPLOT - older, more mature (but starting to suffer
from bit rot) PGPLOT graphics output for figures and such
Processing:
PDL::Transform - image distortion & resampling to arbitrary
coordinate systems, using optimal spatial filtering to avoid aliasing
and artifacts
convolveND - er, convolution - a basic building block of many functions
PDL::Image2D - package of useful 2D-specific processing functions
PDL::ImageND - package of useful arbitrary-dimensional processing
functions
Low-level utilities:
range() - cut out and manipulate arbitrary chunks of an image by
coordinate lookup
Language advantages over IDL:
* Better threading engine for vector calculations (vectorize more
operations)
* Faster interpreter (non-vectorization penalty is ~an order of
magnitude less)
* Distinguishes between cubes and lists of images (3-PDL vs. list of
2-PDLs)
* Better low-level access (via .XS and/or .PP) than IDL (CALL_EXTERNAL)
* Better structured data type (hashes vs. IDL structures)
* Heterogeneous arrays (Perl lists) as well as structured arrays (IDL
arrays; PDLs)
* Access to CPAN
Tips & Pitfalls:
* Do not try to use at() and set() - they are very slow compared to
vector manipulations. (For some reason most new PDL users reach for
'em, but they are only included in the language as a debugging
feature...)
* Use Nice Slice syntax (PDL::NiceSlice) rather than the old-style
"slice" syntax
* Become comfortable with dimensional manipulation - dummy dimensions
and transposition can condense 50 lines of IDL into a single
expression in PDL.
* Always think about how to vectorize - for example, when
manipulating the vicinity of 50 stars in an image, it's better to
stack up the subimages into a little data cube with range(), and
thread over the stacking dimension, than to use a for loop.
* Check CPAN for non-heavy-crunching applications - for example, if
you are interfacing to a database, use an appropriate CPAN module
rather than rolling your own.
* Don't be fooled (by large IDL codebases) into thinking it will be
difficult to port an application into PDL. For example, the
"standard" solar physics software package includes about 50 routines
to manipulate strings and FITS headers, all of which are replaced by
the s/// operator and the hash data type in Perl.
On Mar 4, 2009, at 7:22 AM, Derek Lamb wrote:
> P Kishor wrote:
>> By the way, we have been using IDL for all our image analysis work,
>> and I am looking into how much of that can be replaced by PDL. If
>> there are specific notes about replacing IDL with PDL, please do
>> point
>> me to them
> Google "PDL for impatient IDL users". There's also a link to that
> document from the front page of the PDL wiki. That's a good place
> to start.
>
> cheers,
> Derek
>
> _______________________________________________
> 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
