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: Thu, 3 Jul 2008 08:46:52 -0400 (EDT)


Thanks for the file.  I can view it as text, but I'm sure there's supposed
to be a slicker way of viewing it.  Is a .txi file the same as a .texi file?
I tried running makeinfo on it without any options, but it complained.  Is
it really meant to be viewed in emacs?  (I'm a vi guy to the point that I
have to look for instructions just to quit emacs---but I do have it on my
machine.)

Thomas Scofield


On Wed, 2 Jul 2008, Jaroslav Hajek wrote:

On Wed, Jul 2, 2008 at 9:46 PM, Thomas Scofield <address@hidden> wrote:


On Wed, 2 Jul 2008, Soren 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'.

Soren

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


I had actually started with this; however, the problem with summarizing existing
practice was that I quickly ran out of inspiration. Since then I've
been working on other projects and I've almost forgotten about this.
Attached is what I've put together so far.
If more people think it's already big enough for a changeset I'll make
one and submit. Also, I'll welcome further suggestions.

regards,


--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

reply via email to

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