tor, 26 06 2008 kl. 15:54 -0400, skrev [EMAIL PROTECTED]:
> I'm curious if imread/imwrite are still works in progress in
> octave-forge. I have set it up on both a linux machine and a mac.
> Right now I only have access to the linux box. I can run a command like
>
> im = imread("file.jpg")
>
> and then display the image with imshow. But I get error messages when
> I attempt to load files in other image formats (I've tried just .png
> and .gif). The imread code branches in three directions based on the
> image type: if reading a .jpg file it calls jpgread.oct to import the
> file; if a .png file, it calls pngread.oct; if any other format, it
> calls __magick_read__.oct. In fact, though I have the image package
> installed, the latter two oct-files appear not to exist at all. There
> is source code for both, and I can successfully run mkoctfile on
> pngread.cc, but placing the resulting pngread.oct file in the same
> directory as jpgread.oct does not make reading .png files possible, as
> I get the result
>
> octave: symbol lookup error:
> /home/tom/octave/image-1.0.6/x86_64-pc-linux-gnu-api-v32/pngread.oct:
> undefined symbol: png_check_sig
>
> and then Octave apparently quits un-elegantly. It is the case,
> however, that after putting pngread.oct in that directory, the command
>
> which pngread
>
> produces the output
>
> pngread is the dynamically-linked function from the file
> /home/tom/octave/image-1.0.6/x86_64-pc-linux-gnu-api-v32/pngread.oct
>
> When I run
>
> mkoctfile -I/usr/include/ImageMagick __magick_read__.cc
>
> then the compilation process produces __magick_read__.oct without
> error messages. However, when I place that .oct file in the same
> directory as the others and type
>
> which __magick_read__
>
> I get
>
> error:
> /home/tom/octave/image-1.0.6/x86_64-pc-linux-gnu-api-v32/__magick_read__.oct:
>
> undefined symbol: _ZTIN6Magick9ExceptionE
> which: `__magick_read__' is undefined
>
> which I find surprising, given that it is the same location as
> jpgread.oct and pngread.oct. I left it in that directory anyway and
> tried to use imread to import a .gif, but got the message
>
> warning: isstr is obsolete and will be removed from a future version
> of Octave, please use ischar instead
> error:
> /home/tom/octave/image-1.0.6/x86_64-pc-linux-gnu-api-v32/__magick_read__.oct:
>
> undefined symbol: _ZTIN6Magick9ExceptionE
> error: `__magick_read__' undefined near line 73 column 33
> error: evaluating if command near line 72, column 5
> error: called from `imread' in file `/home/tom/octave/image-1.0.6/imread.m'
> error: evaluating assignment expression near line 5, column 4
>
> which was probably fairly predictable given the above.
>
> One more interesting thing, which may reflect only my ignorance in
> programming dynamically-linked files for Octave. I ran
>
> mkoctfile jpgread.cc
>
> and then replaced the working copy of jpgread.oct with the result of
> the compile I did. At that point I could no longer import .jpg files.
>
> So, my question is whether there is something fairly obvious I am, in
> my ignorance, doing incorrectly? Is this behavior specific to a
> certain platform like Linux (as I said, I cannot test things on my Mac
> right now)? Or is it quite well known among recent users that only
> .jpg files can be read using imread? If the latter, has the interface
> to ImageMagick ever worked? (It has been a matter of some confusion
> in the octave-maintainers list as to why .jpg and .png formats were
> handled separately and only other formats resulted in calls to
> Magick++ library routines, but this would certainly make the reasons
> for that clearer.)
Wow, that was a long e-mail :-)
I wasn't around (I think) when imread/imwrite was developed so I don't
know the entire story, but here's my interpretation:
pngread/write only gets build if you have libpng installed.
jpgread/write only gets build if you have libjpeg installed.
__magick_read/write only gets build if you have libmagick installed.
What imread/imwrite does is to try to make the best of whatever you
happen to have installed. If you have neither of these functions
available imread/write will attempt to use the 'convert' command line
tool if you have that installed. The fact that Linux doesn't have one
standard library for reading all sorts of images that everybody has
installed is creating the need for all this stuff. Nobody likes it, but
that's life.
Hope that gave you just a little bit of insight into the "joy" of image
I/O :-)
Søren
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Octave-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/octave-dev
