Re: imread

[Jaroslav Hajek]

On Wed, Jul 2, 2008 at 9:46 PM, Thomas Scofield <address@hidden> wrote:
>
>
> 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
>

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

contrib.txi
Description: Binary data