Re: imread

[John W. Eaton]

On 15-Jul-2008, Thomas L. Scofield wrote:

| 
| On Jul 14, 2008, at 4:14 PM, John W. Eaton wrote:
| 
| > On 12-Jul-2008, Thomas L. Scofield wrote:
| >
| > | I hope this is what is needed.  I'm sending two changesets (or
| > | whatever is produced by "export tip"), lamely giving them the
| > | extension .changeset.  (I'm not sure what the usual extension is.  I
| > | think I sometimes see .ksh files in the archives.)
| >
| > I don't care what you call the file, but it is slightly easier for me
| > if you send text/plain attachments instead of binary attachments.
| >
| 
| I'm not exactly sure what to do differently.  The files on my machine  
| are text files.  I included them as attachments (email program is the  
| Mac Mail program).  At what stage would they have become binary files?

The attachments arrived with

  Content-Type: application/octet-stream; x-unix-mode=0644;
          name=addImread.changeset

instead of "Content-Type: text/plain".  I'd guess that happens because
your mailer doesn't know what kind of file corresponds to
".changeset", but that's just a guess.

| >   eliminate "using namespace ..." directives
| >
| >   include config.h, not octave/oct.h
| 
| What's the reason behind these last two?

The convention in Octave is to use explicit namespace tags.

Using "#include <octave/oct.h>" won't work inside the Octave source
tree, and I think it is better to avoid including so many unneeded
declarations in every source file.  If you want to know what is
declared where, then use grep.

| I think the same thing, but I wasn't the code's original author.  To  
| date, I've changed only about a line or so of the code.  I would like  
| to write a modified __magick_read__.cc routine for all of the  
| handling and information-gathering of the image files themselves.   
| I'm sure the more mundane things can be wrapped there as well, but  
| given where I am in the knowledge of C++ these days, I'd rather not  
| have to deal with the appropriateness of arguments to imread there.   
| There's already a bit of argument checking in the existing imread  
| routine, and my recollection of C++ file handling in general is that  
| it is harder to check if files exist, etc. than the commands provided  
| in Octave (not to mention that the commands provided in Octave are, I  
| presume, platform independent).

Why would you need to check the existence of the file before trying to
read it?  Isn't it sufficient to just try to read the file, and if
that fails, report the failure?  In any case, if it is necessary to
check first, there are functions in Octave's C++ classes to do that.

jwe