No subject

oldest to newest, and the PAM library can read and write all the others,
basing the format used on the filename extension passed in.

At any rate, actually implementing anything is tabled right at the moment,
but it sounds like the thing to do is to implement a PAM reader/writer, that
also reports the ability to read and write PPM, PGM and PBM files as well.
I can include the PAM library functions in the IJ article, and if it's
eventually included in ITK proper, the library bit will go into
Insight/Utilities.  The library is small enough, simple enough, and portable
enough that I seriously doubt it will cause any problems.


On 8/11/08 12:18 PM, "Bill Lorensen" <bill.lorensen at gmail.com> wrote:

> Actually, if I recall, ppm also supports pgm (portable gray map) and
> pbm (portable bit map). There is a newer format, pam, supported. The
> header is really simple. Maybe these formats (excepting pam) could be
> read directly without the netpbm library. There also may have been
> support for 16 bits.
> 
> Bill
> 
> On Mon, Aug 11, 2008 at 12:29 PM, kent williams
> <norman-k-williams at uiowa.edu> wrote:
>> We are in the process of converting an existing application suite to use ITK
>> instead of the library of home-made functions it currently uses.  One of the
>> tasks Hans has asked me to work on is to create an itk::ImageIO class that
>> reads and writes PPM files to contribute to ITK.
>> 
>> I have a couple of questions.
>> 
>> 1. There is an existing library for reading/writing PPM files -- netpbm.
>> This is one of those old-school, sprawling packages with dozens of programs,
>> covered by a confusing variety of licenses.  Luckily it appears that the
>> library code needed to read and write PPM files is fairly compact and in the
>> public domain.
>> 
>> Would it be OK to include this library source in order to support the
>> PPMImageIO class?  I would of course first submit this as an Insight Journal
>> article.  The library itself is public domain, compact, portable, and
>> stable.
>> 
>> 2. PPM is 2D only, and RGB only. I know there is pixel conversion code in
>> ITK, but how should an ImageIO class behave if it is asked to write a 3D
>> image when the image format only supports 2D?
>> 
>> The one example of a similar reader is itk::JPEGImageIO.h but it seems to be
>> pretty incomplete -- it looks like it doesn't pay any attention to the
>> requested pixel type in the Read method, and just assumes it will be 8 bit
>> pixels.
>> 
>> 
>> 
>> 
>> Notice: This UI Health Care e-mail (including attachments) is covered by the
>> Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential
>> and may be legally privileged.  If you are not the intended recipient, you
>> are hereby notified that any retention, dissemination, distribution, or
>> copying of this communication is strictly prohibited.  Please reply to the
>> sender that you have received the message in error, then delete it.  Thank
>> you.
>> 
>> _______________________________________________
>> Insight-developers mailing list
>> Insight-developers at itk.org
>> http://www.itk.org/mailman/listinfo/insight-developers
>>