<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
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.<BR><BR>
Thanks again for clearing up the haze.<BR>
<BR>
-- Dan Greve<BR>
-- Software Engineer<BR>
-- Northrop Grumman Corp.<BR>
<BR>> From: even.rouault@mines-paris.org<BR>> To: gdal-dev@lists.osgeo.org<BR>> Subject: Re: [Tiff] Re: [gdal-dev] Problem with libTiff on Solaris 10<BR>> Date: Sat, 31 May 2008 17:45:53 +0200<BR>> CC: grevedan@hotmail.com; andy.cave@hamillroad.com; tiff@lists.maptools.org; tiff@lists.osgeo.org; bfriesen@simple.dallas.tx.us<BR>> <BR>> And I suspect that the "_TIFFmemcpy(n,&o->tdir_offset,4)" is also bogus as <BR>> tdir_offset is 64 bit large too.<BR>> That should be fixed too by the same method :<BR>> <BR>> nTemp = (uint32)o->tdir_offset;<BR>> _Tiffmemcpy(n, &nTemp, 4);<BR>> <BR>> Those problems are probably not seen on little endian machines as the first 4 <BR>> bytes contain the lowest 32 bit word, which is the one we want to put into <BR>> the n pointer... I'm also wondering why there's not a test to see if it must <BR>> be swabbed afterwards, as it's done for the tag, type and count fields.<BR>> <BR>> Le Saturday 31 May 2008 17:30:11 Even Rouault, vous avez écrit :<BR>> > Dan,<BR>> ><BR>> > Your fix is not the right one. But I recognize that my previous suggestion<BR>> > could lead into error.<BR>> ><BR>> > In fact, tdir_count field is a uint64 in libtiff 4.0.<BR>> > So the correct fix is :<BR>> ><BR>> > uint32 nTemp = (uint32)o->tdir_count;<BR>> > _Tiffmemcpy(n, &nTemp, 4);<BR>> ><BR>> > Even<BR>> ><BR>> > ---------------------------------------------------------------------------<BR>> >--------<BR>> ><BR>> > RE: [Tiff] Re: [gdal-dev] Problem with libTiff on Solaris 10<BR>> > De :<BR>> > Dan Greve <grevedan@hotmail.com><BR>> > À :<BR>> > Bob Friesenhahn <bfriesen@simple.dallas.tx.us>, Even Rouault<BR>> > <even.rouault@mines-paris.org><BR>> > CC :<BR>> > gdal-dev@lists.osgeo.org, tiff@lists.osgeo.org, Andy Cave<BR>> > <andy.cave@hamillroad.com>, mailing list <tiff@lists.maptools.org><BR>> > Date :<BR>> > Aujourd'hui 16:49:15<BR>> > <BR>> > Sure enough, the pointer n is not null, and throws a sigsegv fault. Aftern<BR>> > changing from<BR>> > <BR>> > *(uint32*)n=(uint32)o->tdir_count; TO<BR>> > <BR>> > _TIFFmemcpy(n, &o->tdir_count, 4)<BR>> > <BR>> > The execution passes this point, but where as *(uint32*)n should be 1, it<BR>> > is 0. This causes errors later in the GDALOpen call on the tiff dataset,<BR>> > which fails with error "TiffFetchNormalTag:incorrect count for<BR>> > "SamplesPerPixel". debugging continues....<BR>> > <BR>> > -- Dan Greve<BR>> > -- Software Engineering<BR>> > -- Northrop Grumman Corp.<BR>> > _______________________________________________<BR>> > gdal-dev mailing list<BR>> > gdal-dev@lists.osgeo.org<BR>> > http://lists.osgeo.org/mailman/listinfo/gdal-dev<BR>> <BR>> <BR><BR><br /><hr />Change the world with e-mail. <a href='http://im.live.com/Messenger/IM/Join/Default.aspx?source=EML_WL_ChangeWorld' target='_new'>Join the i’m Initiative from Microsoft.</a></body>
</html>