Opened 19 years ago

Closed 12 years ago

Last modified 7 years ago

#393 closed defect (fixed)

ECW, GetGeoTransform returns posetive fCellIncrementY

Reported by: llo@… Owned by: warmerdam
Priority: normal Milestone:
Component: GDAL_Raster Version: unspecified
Severity: minor Keywords: ECW
Cc: gaopeng, rprinceley, Mateusz Łoskot

Description (last modified by gaopeng)

Trying to display some sample ECW datasets, using Mapserver/GDAL failed, but 
the ECW files worked with some mapInfo product using a .tab file with 
georefrence info.

The problem was that the images was ignored due to a posetive fCellIncrementY 
returned from GetGeoTransform.

The following fix, was done on the GDAL CVS version from 16 June 03.

I added the following code to ECWDataset::GetGeoTransform, line 466
    if (padfTransform[5] > 0.0)
      padfTransform[5] = -padfTransform[5];
    if (adfGeoTransform[5] > 0.0)
      adfGeoTransform[5] = -adfGeoTransform[5];
To GDALDataset *ECWCreateCopy, before line 671.

The the problem was solved. I dont know if this is a problem in the ECW driver, 
or if the problem is caused by a malformed ECW georeferencing info.

Change History (13)

comment:1 by warmerdam, 19 years ago


I have reviewed a bunch of georeferenced ecw files I have, and they all have
negative fCellIncrementY values.  I am therefore hesitant to apply your change
for fear of messing up the expected behaviour in cases of ungeoreferenced 

So, for now I will do nothing, but if I see it coming up alot I will apply
the suggested patch. 


comment:2 by gaopeng, 12 years ago

Description: modified (diff)
Resolution: invalid
Status: closedreopened

I reopen this ticket as we have many cases where fCellIncrementY has positive value. We have cases reported by the following offices in different regions:


I'd suggest the following fix, which should be safer:

        adfGeoTransform[5] = -fabs(psFileInfo->fCellIncrementY);

comment:3 by warmerdam, 12 years ago

Keywords: ECW added
Priority: lownormal


Can you provide a sample file? Do you have any idea why some files have a positive fCellIncrementY? I'd like to take the issue up with ERDAS to see if they have any advice.

comment:4 by gaopeng, 12 years ago

I uploaded one sample at I can get more if needed.

comment:5 by rprinceley, 12 years ago

Cc: gaopeng rprinceley added

comment:6 by warmerdam, 12 years ago

I have examined the file, and unfortunately it is not practical to do any ground truthing to determine if flipping the sign of the y cell increment would give a proper result. I have emailed Erdas to see if they have any advice on the topic.

comment:7 by warmerdam, 12 years ago

Here is my understanding of how Erdas Imagine use this parameter. If the ecw file is raw (no map-projection info), then fCellIncrementY is positive (i.e., pixelSize->height) If the ecw file has map-projection info, then fCellIncrementY is negative (i.e., -pixelSize->height)

Best regards! Haiyan Qu

comment:8 by warmerdam, 12 years ago

Based on this, I'm going to apply the proposed patch. I can confirm that the file in question is RAW; however, it has an origin so it seems likely that it is in some coordinate system but the coordinate system is just not described in the file. I'm concerned that flipping the sign might still not place the file appropriate.

There is also a risk that this will screw up legitimately south up images though I can't say that I've knowingly encountered such a thing.

comment:9 by warmerdam, 12 years ago

As I'm tentative about this fix, I have only placed it in trunk (r21598) so far. Do you need this in 1.6-esri?

comment:10 by gaopeng, 12 years ago

Yes. Please.

comment:11 by warmerdam, 12 years ago

Resolution: fixed
Status: reopenedclosed

I have pushed the change into 1.6-esri (r21592) and 1.8 (r21593).

I'd appreciate hearing if it causes problems for other files.

comment:12 by Mateusz Łoskot, 7 years ago

Cc: Mateusz Łoskot added

comment:13 by Mateusz Łoskot, 7 years ago

#6516 I reported recently is related (inter-linking).

Note: See TracTickets for help on using tickets.