octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: merging imread and imwrite


From: Daniel J Sebald
Subject: Re: merging imread and imwrite
Date: Fri, 01 Feb 2008 21:54:39 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020

John W. Eaton wrote:
On  1-Feb-2008, Shai Ayal wrote:

| I'm not exactly sure how dynamic linking works, but is there no way to
| add this to octave such that if someone does not use imread/imwrite
| then the libraries don't get loaded to memory?

We can do this by just linking the Magick++ library to the
imread/imwrite/etc. .oct files and not to Octave itself.  This is
currently the way we handle several other libraries.

The "convert" technique does work now.  Interconnecting smaller programs is the 
"unix-y" way of doing things.

At work today I may (repeat *may*) have found a bug in reading a particular PNG file.  It could be the file 
is not encoded correctly, but it does appear correct in "display" and in "gthumb".  
Similar images read through "imread" work correctly.  But this one horizontally is too short and 
then repeats a portion (1/3) of the image.

Looking at "imread" I notice that JPEG and PNG files are actually handled separate from 
ImageMagick, via pngread() and jpgread().  So if there is a bug, it is in pngread().  I see that 
pngread() is a C++ file.  I typed "type pngread" and Octave spits out all the ASCII 
characters in computer hieroglyphics.  Is it supposed to do that for .cc functions?

Anyway, as it currently stands, it appears that ImageMagick isn't all that 
would be needed for the port you are discussing.  Two of the significant 
formats are handled differently.  Does that have any significance to the 
discussion?

Dan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]