octave-maintainers
[Top][All Lists]
Advanced

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

Re: imread


From: Thomas Scofield
Subject: Re: imread
Date: Wed, 2 Jul 2008 15:46:31 -0400 (EDT)



On Wed, 2 Jul 2008, S?ren Hauberg wrote:

tir, 01 07 2008 kl. 17:00 -0400, skrev Thomas Scofield:
I'm attaching the changed code as .m (imread.m) and .cc (__magick_read__.cc)
files, which I hope is workable.  The way I compile __magick_read__.cc is
with the command

   mkoctfile __magick_read__.cc `GraphicsMagick++-config --cppflags` 
-lGraphicsMagick++ -lGraphicsMagick

which presumes you have the GraphicsMagick libraries in the right places
which, for me, was as specified in the note I sent earlier today starting
this thread.  GraphicsMagick++-config is a script whose purpose I don't
quite understand (it may not be necessary).  On my debian-based machine
it came with GraphicsMagick, and parallels the script Magick++-config that
came with one of the ImageMagick packages.  I include the script in the
mkoctfile command above because in the Makefile for the image-1.0.6 package
the ImageMagick version of the script appears in the same position.

I've only played with this for a couple of seconds for Octave 3.0.0, so
this'll be brief. I've tried

 I = imread ("some_pic.something");
 imshow (I)

and the result looks wrong with all the images I've tried. This might be
a bug in 'imshow', but I haven't had the time to investigate.

Can you say more about what you mean by "looks wrong"?  I have noticed
that imshow(im) displays images as quite washed out on my linux machine---far
different than if I use "display <imageFile>" or "gm display <imageFile>" to
display the image from a terminal---but that the results are fairly comparable
between the two methods on my mac.  But, then, it is on the linux machine that
I have been making changes to imread().  When I re-install the image-1.0.6
package from scratch (so as to return to unmodified code), the problem
persists.  Does this sound like what you're experiencing?

As to the code, I have a few comments:

 1) When I compile with '-Wall' I get a warning at line 94. Changing
line 22 from 'int i = mapsize;' to 'unsigned int i = mapsize;', fixes
this.

 2) The code formatting doesn't seem to match Octaves. Instead of
writing

for (...) {
   ...
}

please write

for (...)
 {
   ...
 }

and same for if statements, while loops, etc. If the loop body only
contains one line, then omit the curly brackets.

Instead of writing

for(...)

please write

for (...)

notice the extra space before the parenthesis. Same goes for if
statements, function calls, etc.

I'll report back when I know if my problems are related to 'imread' or
'imshow'.

S?ren

These comments pertain to lines of code which were there before I began
working on imread().  Nevertheless, reading through messages to
octave-maintainers has made me aware that there are code conventions,
at least for code that goes into core Octave, and I am happy to make
such changes.  There was some discussion in April (perhaps other months
too) of putting together a page of "octave contributing guidelines", but
I've not found the result anywhere.  Do you know of the existence of a
webpage or other document that summarizes coding conventions?

Thomas Scofield

reply via email to

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