Getting past imread fault in Octave 2.1.73

[Chris Zarowski]

Hello everyone.

 

I do not know if this will be of use to anyone, but I thought

I should mention it anyway. It is a way to get past

a problem I emailed about recently ...

 

Problem:

I have found that imread() in Octave 2.1.73 (running

under Windows XP w. ServicePack 2) does not work.

I have ImageMagick now but this does not eliminate

my problem.

 

I do not know enough about the 'guts' of Octave to

fix a problem like this, and a patch seems unavailable.

I do not wish to attempt a re-install, or major re-build.

 

Workaround (a kludge):

Java J2SE, JAI (Java Advanced Imaging) are freely

available from Sun Microsystems.  The NetBeans

IDE from Sun is also free, but the BlueJ IDE (free)

is much easier to use and takes up a lot less disk space.

 

Using JAI it is not hard to read in digital images in

a wide format range, and then output the image as

an integer array to a file.

 

The integer array form is easily read in by Octave

2.1.73 using fscanf. Of course, once the integer

array is read in then one may process it in any manner

that one sees fit. Image display function imshow()

appears to function (more-or-less), and so a processed

result is easily displayed, and subsequently saveable

as a .bmp file.

 

Cautions/Remarks:

1) Converting an image to an integer array expands

file size as bytes get turned into 4-byte integers.

2) When the Octave file reader and imshow have

done their work, and the Octave session ends I have

noticed that Octave 2.1.73 loves to create very large

Octave-Core files (e.g., 8 Mbytes and up).

 

I do not know why this happens, but Octave-Core

can be deleted.

3) I have not tried color images yet as my application

does not need this.

4) Of course, JAI is for digital image processing and

one may attempt to do any processing of interest

using Java/JAI, and forget about Octave altogether.

 

However, JAI is not so easy to use, and one may not

like to spend much time learning Java/JAI. Also, 

even if one is an expert in Java/JAI, algorithm

development tends to be faster in Octave than

Java/JAI. (Consistent with the notion that scripting

languages are for rapid prototype development.)

 

Christopher J. Zarowski, Ph. D., P. Eng. (Ontario)
     IEEE Senior Member
     NanoDotTek
     http://www.nanodottek.com