[gdal-dev] Bigger file size from 64-bit than 32-bit
Jukka Rahkonen
jukka.rahkonen at mmmtike.fi
Thu Jan 16 12:16:17 PST 2014
Even Rouault <even.rouault <at> mines-paris.org> writes:
>
> What should be determined is if the problem is on the read side (JPEG 2000
> decoding) or at the write side (JPEG in TIFF compression). Perhaps you could
> translate to uncompressed TIFF. My feeling is that the problem must be on the
> read side and that you get more or less random images at each read
attempt. You
> could also run gdalinfo -checksum on the JPEG2000 image itself and see if it
> returns a constant value.
Hi,
I have studied the situation a bit and the reason is clearly somehow related
to Kakadu.
- My problematic originals are compressed with Kakadu SDK 3.4. Tamas
compiled me also the native Kakadu demo programs and if I decompress images
with 64-bit kdu_expand v. 7.3.2 the result is corrupted just like the ones
that come from gdal_translate.
- If I convert the originals with the same 64-bit GDAL but with JP2ECW (SDK
3.x) the result is good.
- Then the odd thing, if I decompress images with kdu_expand v. 6.0, 32-bit,
and compress again into lossless JPEG2000 also with v. 6.0 Kakadu, these new
images can be converted with 64-bit GDAL and v. 7.3.2 Kakadu driver just fine.
Conclusion: Kakadu 7.3.2, 64-bit, has troubles at least with some images
which are compressed with ancient Kakadu 3.4. Same images which are
compressed by using identical options but with Kakadu v. 6.0 do no suffer
from these problems with Kakadu 7.3.2, 64-bit.
I guess I will write a note to Kakadu forum.
-Jukka Rahkonen-
I used Kakadu binaries of version 6.0 and uncompressed some originals with
kdu_expand and recompressed them with kdu_compress v. 6.0. Then I used my
original command with 64-bit GDAL and Kakadu 7.3.2 plugin and the result was
perfect.
More information about the gdal-dev
mailing list