imread
Thomas Scofield
scofield at calvin.edu
Wed Jul 2 14:46:31 CDT 2008
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
More information about the Octave-maintainers
mailing list