[Gdal-dev] img format resizing

list67 at netscape.net list67 at netscape.net
Fri Apr 2 14:08:52 EST 2004


Frank Warmerdam <warmerdam at pobox.com> wrote:

>list67 at netscape.net wrote:
>> Hello.
>> 
>> I have a possible bug to report.
>> 
>> I have a .img file.  When I run:
>> gdalwarp -rb -of HFA -ot Byte -wm 512 -ts 1487 2899 ./beforeResize.img ./afterResize.img
>> the afterResize.img file is upside down.  Does anyone know if there is 
> > something about the above command that should be changed?
>
>Mike,
>
>My guess is that your image has no georeferencing so the source
>image coordinate system "y" is increasing as you move from the top
>to the bottom, as opposed to the "y" decreasing from top to bottom
>as would occur in common projected or geographic coordinate systems.
>
>The warper will generally get ungeoreferenced images upside down I expect,
>though I haven't tried this myself.
>
>....
>
>Hmm, I just tried it, and gdalwarp seems to error out if the is
>no georeferencing (which is good).
>
>Could you provide a gdalinfo report on the input file?

Frank,

Here are the gdalinfo reports for the before and after resizing img files:

gdalinfo ./beforeResize.img 
Driver: HFA/Erdas Imagine Images (.img)
Size is 1487, 2900
Coordinate System is:
LOCAL_CS["Unknown",
    UNIT["meters",1]]
Origin = (0.000000,0.000000)
Pixel Size = (0.00010000,0.00010000)
Corner Coordinates:
Upper Left  (   0.0000000,   0.0000000) 
Lower Left  (   0.0000000,   0.2900000) 
Upper Right (   0.1487000,   0.0000000) 
Lower Right (   0.1487000,   0.2900000) 
Center      (   0.0743500,   0.1450000) 
Band 1 Block=64x64 Type=Byte, ColorInterp=Undefined
Band 2 Block=64x64 Type=Byte, ColorInterp=Undefined
Band 3 Block=64x64 Type=Byte, ColorInterp=Undefined
Band 4 Block=64x64 Type=Byte, ColorInterp=Undefined



gdalinfo ./afterResize.img 
Driver: HFA/Erdas Imagine Images (.img)
Size is 1487, 2899
Coordinate System is:
LOCAL_CS["Unknown",
    UNIT["meters",1]]
Origin = (0.000000,0.290000)
Pixel Size = (0.00010000,-0.00010003)
Corner Coordinates:
Upper Left  (   0.0000000,   0.2900000) 
Lower Left  (   0.0000000,   0.0000000) 
Upper Right (   0.1487000,   0.2900000) 
Lower Right (   0.1487000,   0.0000000) 
Center      (   0.0743500,   0.1450000) 
Band 1 Block=64x64 Type=Byte, ColorInterp=Undefined
Band 2 Block=64x64 Type=Byte, ColorInterp=Undefined
Band 3 Block=64x64 Type=Byte, ColorInterp=Undefined
Band 4 Block=64x64 Type=Byte, ColorInterp=Undefined

Do you know of anything I can do to prevent the upside downness?

>> I'm using a cvs version of gdal that was updated today.  The 
> > beforeResize.img file is about 4.5 MB when gzipped.
>> 
>> Also, the reason I'm using the .img format is that I have a program 
> > that needs to be able to work with large image files (36GB is the max size
> > so far).  The geotiff format has the file size limit.  The .img format seems
> > to get unexpectedly large when making modifications to the file.  I don't
> > have any test results to back this up.  Can anyone recommend one of the
> > other image formats that are suitable for large images files?
>
>What exactly do you mean by "making modifications to the file"?  Are you
>dynamically re-write image data after the creation pass?  While this should
>- in theory - work, it isn't a path that is well tested.  There might well
>be a bug.  Please provide some more detail on what you are doing and what
>is going wrong and I might be able to figure out whats happening.

An approximately 36GB img file was reprojected with gdalwarp from something like the following coordinate system:

  <SRS>PROJCS[&quot;unnamed&quot;,GEOGCS[&quot;NAD83&quot;,DATUM[&quot;North_American_Datum_1983&quot;,SPHEROID[&quot;GRS 1980&quot;,6378137,298.2572221010042,AUTHORITY[&quot;EPSG&quot;,&quot;7019&quot;]],AUTHORITY[&quot;EPSG&quot;,&quot;6269&quot;]],PRIMEM[&quot;Greenwich&quot;,0],UNIT[&quot;degree&quot;,0.0174532925199433],AUTHORITY[&quot;EPSG&quot;,&quot;4269&quot;]],PROJECTION[&quot;Transverse_Mercator&quot;],PARAMETER[&quot;latitude_of_origin&quot;,0],PARAMETER[&quot;central_meridian&quot;,-117],PARAMETER[&quot;scale_factor&quot;,0.9996],PARAMETER[&quot;false_easting&quot;,500000],PARAMETER[&quot;false_northing&quot;,0],UNIT[&quot;unknown&quot;,1],AUTHORITY[&quot;EPSG&quot;,&quot;26911&quot;]]</SRS>

using something like -t_srs "+proj=longlat +ellps=WGS84 +datum=WGS84".  After this reprojection I think (I had to delete the file to free up space) that the new .img file was approximately 60 GB.  Maybe I just wasn't expecting there to be such a difference in file size.  After reprojecting, a program added a alpha layer to the .img file.  This made the file approximately 90GB.  That increase in file size was expected.  And finally there was a resize which resulted in a 122 GB .img file.  So I guess that it was just the size after reprojection that I wasn't expecting.

Thanks for your help.

    Mike

>Best regards,
>-- 
>---------------------------------------+--------------------------------------
>I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
>light and sound - activate the windows | http://pobox.com/~warmerdam
>and watch the world go round - Rush    | Geospatial Programmer for Rent
>
>_______________________________________________
>Gdal-dev mailing list
>Gdal-dev at remotesensing.org
>http://remotesensing.org/mailman/listinfo/gdal-dev
>

__________________________________________________________________
Introducing the New Netscape Internet Service. 
Only $9.95 a month -- Sign up today at http://isp.netscape.com/register

Netscape. Just the Net You Need. 

New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp



More information about the Gdal-dev mailing list