[Tiff] Re: [gdal-dev] Problem with libTiff on Solaris 10

[Dan Greve]

I think I"ll just wait until libTiff is fixed.  I replace frmts/gtiff/libtiff from gdal-1.5.1 build with frmts/gtiff/libtiff from gdal-1.4.1 build.  voila, works like a champ.  It meets my requirements of just creating a compressed geotiff from an uncompressed nitf.  (I would rather create a compressed nitf from uncompressed geotiff, but this is not possible with jpeg & Create() in NITF.) As a result i go from uncompressed nitf to compressed geotiff, to compressed nitf using CreateCopy.
Thanks again for clearing up the haze.
 
-- Dan Greve
-- Software Engineer
-- Northrop Grumman Corp.
> From: even.rouault at mines-paris.org> To: gdal-dev at lists.osgeo.org> Subject: Re: [Tiff] Re: [gdal-dev] Problem with libTiff on Solaris 10> Date: Sat, 31 May 2008 17:45:53 +0200> CC: grevedan at hotmail.com; andy.cave at hamillroad.com; tiff at lists.maptools.org; tiff at lists.osgeo.org; bfriesen at simple.dallas.tx.us> > And I suspect that the "_TIFFmemcpy(n,&o->tdir_offset,4)" is also bogus as > tdir_offset is 64 bit large too.> That should be fixed too by the same method :> > nTemp = (uint32)o->tdir_offset;> _Tiffmemcpy(n, &nTemp, 4);> > Those problems are probably not seen on little endian machines as the first 4 > bytes contain the lowest 32 bit word, which is the one we want to put into > the n pointer... I'm also wondering why there's not a test to see if it must > be swabbed afterwards, as it's done for the tag, type and count fields.> > Le Saturday 31 May 2008 17:30:11 Even Rouault, vous avez écrit :> > Dan,> >> > Your fix is not the right one. But I recognize that my previous suggestion> > could lead into error.> >> > In fact, tdir_count field is a uint64 in libtiff 4.0.> > So the correct fix is :> >> > uint32 nTemp = (uint32)o->tdir_count;> > _Tiffmemcpy(n, &nTemp, 4);> >> > Even> >> > ---------------------------------------------------------------------------> >--------> >> > RE: [Tiff] Re: [gdal-dev] Problem with libTiff on Solaris 10> > De :> > Dan Greve <grevedan at hotmail.com>> > À :> > Bob Friesenhahn <bfriesen at simple.dallas.tx.us>, Even Rouault> > <even.rouault at mines-paris.org>> > CC :> > gdal-dev at lists.osgeo.org, tiff at lists.osgeo.org, Andy Cave> > <andy.cave at hamillroad.com>, mailing list <tiff at lists.maptools.org>> > Date :> > Aujourd'hui 16:49:15> >  > > Sure enough, the pointer n is not null, and throws a sigsegv fault. Aftern> > changing from> >  > > *(uint32*)n=(uint32)o->tdir_count;            TO> >  > > _TIFFmemcpy(n, &o->tdir_count, 4)> >  > > The execution passes this point, but where as *(uint32*)n should be 1, it> > is 0. This causes errors later in the GDALOpen call on the tiff dataset,> > which fails with error "TiffFetchNormalTag:incorrect count for> > "SamplesPerPixel". debugging continues....> >  > > -- Dan Greve> > -- Software Engineering> > -- Northrop Grumman Corp.> > _______________________________________________> > gdal-dev mailing list> > gdal-dev at lists.osgeo.org> > http://lists.osgeo.org/mailman/listinfo/gdal-dev> > 
_________________________________________________________________
Change the world with e-mail. Join the i’m Initiative from Microsoft.
http://im.live.com/Messenger/IM/Join/Default.aspx?source=EML_WL_ChangeWorld
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20080531/0ebfeae8/attachment.html