Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#2988 closed defect (fixed)

SetProjection() fails on jpeg compressed GeoTIFFs with latest 1.6 branch

Reported by: warmerdam Owned by: warmerdam
Priority: highest Milestone: 1.6.1
Component: GDAL_Raster Version: 1.6.0
Severity: normal Keywords: GTiff
Cc: hobu, vjetly

Description

Frank,

I cannot get the SetProjection() method to work correctly on JPEG compressed tiled tiffs with internal pyramids in the 1.6.0-9 OSGeo4W build. Calling the method after opening a file in write mode seems to do nothing and for some reason when called in a loop it quietly exits after the first iteration.

The method works find on simple GeoTIFFs. Also SetProjection() in the previous build 1.6.0-8 works fine on all GeoTIFFs. I have attached a sample script and data to illustrate the issue. The source data directory is hard_coded in the script.

Please let me know what you find.

Thanks. Vikalpa

from osgeo import gdal,osr
import os,glob,sys


denver_source = r'E:\DEV\2009\Frank\Denver'

def setProjection(inimage):
    sref = osr.SpatialReference()
    sref.ImportFromEPSG(26911)
    proj_wkt = sref.ExportToWkt()
    dset = gdal.Open(inimage,1)
    dset.SetProjection(proj_wkt)


for image in glob.glob(r'%s\*.tif' %denver_source):
    print image
    setProjection(image)

Change History (4)

comment:1 by warmerdam, 15 years ago

Owner: changed from vjetly to warmerdam
Priority: normalhighest
Status: newassigned

I am able to reproduce the problem on linux with GDAL 1.6 branch on non-jpeg GeoTIFF that have overviews. I'm boosting this to highest priority as a release blocker. The script is crashing with infinite recursion looking like:

(gdb) where 5
#0  0x00002b309c76f980 in GTiffDataset::SetDirectory (this=Cannot access memory at address 0x7fff0ef15ff8
)
    at geotiff.cpp:3830
#1  0x00002b309c76fc35 in GTiffDataset::FlushDirectory (this=0x917b10)
    at geotiff.cpp:2651
#2  0x00002b309c76fa10 in GTiffDataset::SetDirectory (this=0x917b10, 
    nNewOffset=21360) at geotiff.cpp:3846
#3  0x00002b309c76fc35 in GTiffDataset::FlushDirectory (this=0x917b10)
    at geotiff.cpp:2651
#4  0x00002b309c76fa10 in GTiffDataset::SetDirectory (this=0x917b10, 
    nNewOffset=21360) at geotiff.cpp:3846
(More stack frames follow...)
Current language:  auto; currently c++

Investigating further.

comment:2 by warmerdam, 15 years ago

Resolution: fixed
Status: assignedclosed

I have confirmed that the ppoActiveDSRef and the loaded directory were being left out of sync after opening overview directories from the main OpenOffset() request. I have restructured things a bit to ensure they stay in sync in trunk (r16986) and 1.6 branch (r16987). This seems to correct the problem.

I'd note that things were working in trunk for the stated situation, but only because projection load deferrable perturbed things. A crash could be triggered in trunk by setting metadata on a geotiff with overviews.

Fragile stuff...

I will produce a new OSGeo4W package for Vikalpa once 1.6.1RC2 is issued.

comment:3 by warmerdam, 15 years ago

Cc: vjetly added

Added Vikalpa to cc - somehow he was neglected initially.

comment:4 by Even Rouault, 15 years ago

Test added in r16988

Note: See TracTickets for help on using tickets.