TIFFs produced with IFD offset not on word boundary as required by spec

[lblatchford]

Describe the bug
Sometime between version 3.9.3 and 3.1.0, the offset of the first IFD in bytes 4-7 in TIFF images produced for the same data changed from a location on a word boundary as required by the spec (even value) to a location not on a word boundary (odd value). This is causing other software to fail to process the TIFFs as they do not comply with the specification.

Version information
Observed with 3.10.1 and 3.12.0

2. The exact output of java --version (or java -version for older Java releases).

Tests with 3.12.0 performed with:

openjdk version "17.0.13" 2024-10-15
OpenJDK Runtime Environment (Red_Hat-17.0.13.0.11-1) (build 17.0.13+11-LTS)
OpenJDK 64-Bit Server VM (Red_Hat-17.0.13.0.11-1) (build 17.0.13+11-LTS)

3. Extra information about OS version, server version, standalone program or web application packaging, executable wrapper, etc. Please state exact version numbers where applicable.

RHEL 9.4

To Reproduce

The behavior is demonstrated by simply converting a random JPG to TIFF using the following code:

BufferedImage image = ImageIO.read( new File ( inputJPEG ) );
ImageIO.write( image, "TIFF", new File (outputTIFF ) );

The IFD offset in bytes 4-7 of the TIFF file is an odd value.

Expected behavior

The offset of the first IFD should be on a word boundary per the TIFF spec:

Bytes 4-7 The offset (in bytes) of the first IFD. The directory may be at any location in the
file after the header but must begin on a word boundary. In particular, an Image
File Directory may follow the image data it describes. Readers must follow the
pointers wherever they may lead.

Example code

See above

Sample file(s)

Use any JPEG as the input file for the above code snippet

Stack trace
n/a

Screenshots

No screenshot but example of xxd output:

$ xxd out.tif | head -1
00000000: 4d4d 002a 0000 0037 0008 0008 0008 5477 MM.*...7......Tw

Additional context
n/a

[haraldk]

Thanks for reporting this, I'll look into it!

In the meantime, don't hesitate to create a PR for the issue. 😀