octave-maintainers
[Top][All Lists]
Advanced

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

imread


From: Thomas Scofield
Subject: imread
Date: Tue, 1 Jul 2008 12:41:36 -0400 (EDT)


I have modified imread to use GraphicsMagick libraries in place of
ImageMagick ones.  The version of imread I worked from is the one
in the latest stable(?) release from octave-forge, not the one
in development.  (I'm not yet admitted to the developers list.)

The main edits involved changing library and header file names
and locations.  I did this on a linux machine, and there it was
the case that the header file Magick++.h used in the C++ API for
ImageMagick was located in /usr/include/, subsidiary header files
were found in /usr/include/Magick++/, and the libraries were in
/usr/lib; the corresponding files for the C++ API for GraphicsMagick
were found in /usr/include/GraphicsMagick/ and /usr/lib.  I'm not
versed in how to make the corresponding changes work equally well
on other platforms.

I have dropped the exceptional handling of .jpg and .png files in
imread.m, so that GraphicsMagick takes care of importing all image
formats.  I ran a couple of tests while both implementations were
possible with code like

  octave:32> x = cputime(); im = imread("owl.png"); cputime()-x

and found that .png files seem to get loaded about twice as quickly
with GraphicsMagick as they were when handled separately; .jpg files
(older ones, I believe---I don't think I'm talking about jpeg2000
ones; has the extension changed for the newer format?), on the other
hand, appear to require about 25% more time to load than when handled
using the prior exceptional method.

To be clear, thus far I've only undertaken the task of making imread()
work using GraphicsMagick over Imagemagick which, in the opinion of
John Eaton, Soren Hauberg (and perhaps others), has a more stable API.
Besides that (and another minor change), imread() works as it did
before.  Perhaps the grafting of imread() into core Octave should,
right from the start, employ a more systematic look at whether the
function behaves in all respects like its Matlab counterpart.  That
is something I am willing to do, but have not yet.  I next will look
at imwrite(), which seems like it ought to go smoothly.

So, just how and to whom should I submit the changed files for review
by others?  As I said, I'm not yet on the developers list at
octave-forge.  I'm also not yet versed in the use of subversion nor
mercurial (any efforts I made to use mercurial were for a mac, and not
terribly successful; I presume it is easier from the linux machine I
am using right now).  Just what should I send?  People on the list
talk about changelogs and diffs (or, at least, they used to when CVS
was being used).  I get the impression that these diffs were not
produced from the unix command line as in

 $ diff file1 file2

Thanks.

Thomas Scofield



reply via email to

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