Re: [Openev-discuss] Can't import gdal-created images

[Frank W. <war...@po...>]

Carolyn Johnston wrote:
> Hi everyone (hi Gillian and Peter),
> 
> here is my first in what will no doubt be a lot of posts.
> 
> I have OpenEV v1.6 running on windows (I just downloaded it yesterday to 
> make sure I had the latest version). I also have a homegrown program 
> running on Solaris that reads and writes images with gdal-1.1.8, also 
> downloaded and built with gcc/c++ a couple of days ago.
> 
> I am finding it difficult-to-impossible to either import or open files 
> in OpenEV that are created with the gdal libraries on Solaris. When I 
> try to import these files I get a dump of thousands of lines of the 
> following error:
> 
>   Error 1: TIFFAppendToStrip:fused_seg_bath.tif: Write error at scanline 
> <number>

Carolyn,

I am not sure why this is happening, but when you "import" OpenEV will create
a new whole copy of the image in a TIFF file.  I can't remember the exact rules
used to decide where to put this file, but I think it is in the current working
directory.

If the data imported is too large for the available disk space, or if the
image is too large (uncompressed with overviews) then I could imagine
something like the above happening.

> When I try to open these files, sometimes it works: sometimes OpenEV 
> just freezes. Usually I don't see output.
> 
> I've run gdalinfo on these files, both from the Solaris installation and 
> from OpenEV/bin, and it works just fine in both cases.
> 
> Could this be a big-endian/little-endian issue?

While it is theoretically possible, I am doubtful it is an endian problem.
However, there was a bug fixed on May 9th with opening files in OpenEV.  In
particular there is a portion of the application that tries to load one line
of the file to see if it is a project file.  This was very unsafe in the case
of binary files which happened to have no newlines for a *long* time, and would
result applications freezing.  I fixed this in CVS but I suspect it was not in
Gillian's 1.6 release which I believe predated the fix.

Could you check the version information at the top of the pymod/gvutils.py
file, and see if it includes Revision 1.22 (about is_project_file())?

If not, I would suggest saving the attached version of gvutils.py over that one.

I would add that if you can narrow down the import problem, and you feel it is
a GDAL bug you can submit it in the GDAL Bugzilla area.

Best regards,

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, war...@po...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent