Promoted extended-depth grayscale (9-15 bits -> u16, 17-31 bits -> u32)
can carry bits above the declared depth after the horizontal predictor,
which reconstructs prev+delta in the promoted storage width rather than
modulo 2^BitsPerSample. This underflowed `max - v` in invert_colors (the
image-rs/image-tiff#396 panic in debug, wrong pixel in release) and left
junk in the high bits of the non-inverted output (#396 review, @197g:
"clamp the channel values in the non-inverted color case").
An n-bit predictor delta is stored in exactly n bits, i.e. modulo 2^n,
so reconstruction is defined modulo 2^n as well. Since 2^n divides the
u16/u32 storage modulus, masking each promoted sample with (1<<n)-1 once
after the predictor yields exactly the mod-2^n value -- including
legitimate wrap-arounds -- and also bounds any out-of-range sample from
malformed input. invert_colors' `max - v` is then always in range,
superseding the targeted saturating_sub from #396.
mask_samples_to_bit_depth runs in every integer decode branch of
expand_chunk; outside the extended-depth unpacking branch it is a
statically provable no-op (promoted layouts, declared < storage, occur
only there -- sub-byte depths keep byte-granular storage and reject the
horizontal predictor, standard depths have declared == storage, and the
float predictor requires IEEEFP samples that are never promoted), so the
branches cannot diverge.
Adds exact-pixel regression tests on hand-built TIFFs: 12/20-bit
wrap-around (plain and WhiteIsZero) and a 9-31-bit encode/decode
identity sweep, alongside the two fuzzer-minimized panic seeds. A
saturating clamp corrupts the wrap-around cases -- 12-bit [4095, 0, 1]
is stored as deltas [4095, 1, 1] and masks back to [4095, 0, 1], but
saturating produced [4095, 4095, 4095] -- so the tests lock the modular
semantics.
`1usize << bits_per_sample` panics when bits_per_sample >= 64.
Use checked_shl to return a LimitsExceeded error instead.
Found by fuzzing decode_comprehensive with a BE TIFF containing
PhotometricInterpretation=RGBPalette and BitsPerSample=83.
The bounds `Read + Seek` are not representational so we may remove them
from the struct itself. This also allows us to use more precise bounds
for direct access to the inner stream, especially were that does not
seek.
Groups operations according to their use case.
log16_to_y() uses f32::exp() which is not required to be correctly
rounded by IEEE 754. Apple libm on arm64 differs by 1 ULP from glibc
on x86_64, producing different CRC32 checksums for the decoded output.
Same issue as off_luv32.tif which was already demoted in commit 617dc6e.
A deterministic LUT-based approach could fix both in a follow-up.
Three 16x16 bilevel fax3 test images covering the key Group 3 variants:
- seq-1c-1b-fax3: basic G3, no fill bits, MSB-first fill order
- seq-1c-1b-fax3-fillbits: G3 with T4Options fill bits (byte-aligned EOLs)
- seq-1c-1b-fax3-lsb: G3 with FillOrder=2 (LSB-first)
All use MinIsWhite photometric with inverted sequential pattern, producing
the same decoded CRC32 hash (71f6a21a) as the uncompressed 1-bit images.
Cross-validated: libtiff writes the images, both libtiff and image-tiff
read them back and agree on the decoded data.
Fix two CI failures on i686 and powerpc:
1. chunk_col_stride overflow: RowsPerStrip = u32::MAX causes
data_row_bytes * chunk_height to exceed 32-bit usize. Clamp
the chunk height to the image height before computing stride
values, since a chunk never contributes more rows than the
image contains. Applied to both readout_for_size() and
set_row_stride().
2. off_luv32.tif hash mismatch: the LogLuv decoder produces
platform-dependent output (different hashes on x86_64, i686,
and powerpc), so demote to smoke test.
Add YCbCrUpsamplingReader that converts chroma-subsampled YCbCr block
data to full-resolution 3-bytes-per-pixel output. Each block of h×v
pixels stores h*v Y samples plus one shared Cb and Cr sample; the
reader expands these into per-pixel (Y, Cb, Cr) triples.
This enables decoding YCbCr TIFFs with any supported compression
method (uncompressed, LZW, Deflate, etc.), not just JPEG. Two more
libtiffpic test images now decode with verified hashes:
- dscf0013.tif (uncompressed YCbCr 2,1 subsampling)
- ycbcr-cat.tif (LZW-compressed YCbCr 2,2 subsampling)
The remaining two YCbCr test images (smallliz.tif, zackthecat.tif)
use Old JPEG compression (type 6) which is a separate unsupported
feature.
Add Group3Reader for decoding CCITT Group 3 (T.4) 1D compressed TIFF
images. The fax crate's Group3Decoder has a bug where new() verifies
but doesn't consume the initial EOL marker, causing its lookup tables
to destructively consume bits from the EOL code. We work around this
by using the crate's lower-level white::decode / black::decode
functions and handling EOL markers ourselves.
Also adds FillOrder tag (266) support: FillOrder=2 (LSB-to-MSB,
common in fax images) is handled by reversing bits in each byte
before decoding. This applies to both Group 3 and Group 4 readers.
Both libtiffpic fax test images (fax2d.tif, g3test.tif) now decode
correctly with verified CRC32 hashes.
Upgrade the libtiffpic test harness from decode-only smoke tests to
full output verification using CRC32 reference hashes. 50 of 61 images
now have hash-verified decoded output; the remaining 11 use unsupported
formats (YCbCr subsampling, Fax3, etc.) and remain as decode-only tests.
Uses read_image_to_buffer (the non-deprecated API) with ByteOrder::convert
for cross-platform LE normalization.
Remove the 13 individual depth tests from decode_images.rs — they tested
the same libtiffpic flower images that are now hash-verified here.
Address PR review feedback:
- Remove benches/decode.rs which referenced non-existent gen_bench_tiff.c
- Simplify compute_tiff_hash: replace 66-line match block with
as_buffer().as_bytes() + ByteOrder::convert for LE normalization
- Use TIFF Type repr(u16) as hash discriminant instead of ad-hoc u8
- Rename all 74 seq test images to match updated hashes
- compute_tiff_hash now panics on unhandled ColorType variants instead
of silently using a fallback discriminant
- print_seq_hashes correctly identifies existing 8-char hex hash suffix
vs non-hash filename segments
Move 74 seq-*.tiff test images to tests/images/seq/ and embed a CRC32
hash of the full decoded output (dimensions, color type, sample data)
as the last filename segment. Replace 75 individual test functions with
one generic verify_all_seq_images test that decodes each file and
validates its hash against the filename.
This catches byte-order, bit-alignment, stride, padding, and value
errors that sum-based tests would miss (e.g., swapped pixels preserve
the sum but change the hash). Adding new test images only requires
dropping a correctly-named file in seq/ — no test code changes needed.
Replace Python-generated test TIFFs with libtiff-generated ones to
eliminate circular validation. The C program (gen_seq_tiff.c) uses
libtiff's TIFFWriteScanline with MSB-first packed bit streams.
Cross-validated: tifffile independently confirms all 27 images match
the original Python-generated versions byte-for-byte. tiffinfo validates
all IFD structures. All 27 image-tiff decode tests pass unchanged.
TIFF files can store samples at non-standard bit depths (e.g. 10, 12,
14, 24 bits) packed tightly in a continuous bit stream. Previously
these were rejected as unsupported color types.
This adds:
- MSB-first bit extraction from packed byte streams (unpack_bits,
extract_bits_msb) to expand N-bit samples to standard-width output
(9-16 bit → u16, 17-32 bit → u32)
- Output buffer sizing using the promoted sample width instead of the
packed bit depth (output_bits_per_sample field in ReadoutLayout)
- A new code path in expand_chunk that reads packed rows, unpacks to
standard-width samples, then applies predictor and color inversion
- Horizontal predictor support for extended depths
Tested with 12-bit grayscale and RGB images (existing test suite),
plus all libtiffpic depth test images (10/12/14/24-bit in gray, RGB
contig, and RGB planar configurations).
Read the ColorMap tag (320) for RGBPalette images and return raw
palette indices as the decoded data with ColorType::Palette(n).
Changes:
- Read and validate ColorMap tag during IFD parsing (3 * 2^bps entries)
- Return ColorType::Palette from colortype() for RGBPalette images
- Accept Palette in expand_chunk validation (standard + sub-byte depths)
- Expose color_map() method on Decoder for palette lookup
- Add tests for 1-bit, 4-bit, 8-bit palette images with checksums
- Add test verifying ColorMap accessibility and structure
The decoder returns raw palette indices; consumers apply the lookup
using the color map returned by Decoder::color_map().
Add support for encoding TIFF images with the floating-point predictor,
which improves compression ratios for floating-point image data.
The floating-point predictor works by:
1. Converting floats to big-endian bytes
2. Shuffling bytes so all first bytes are together, all second bytes, etc.
3. Applying byte-level horizontal differencing across the buffer
This complements the existing decoding support for Predictor 3.
Supported types: Gray32Float, Gray64Float, RGB32Float, RGB64Float,
RGBA32Float, RGBA64Float, CMYK32Float, CMYK64Float.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Two tests are disabled, both related to tiles, since they do not follow
the fully released spec themselves but incidentally decode with libtiff
anyways. The two images (`cramps-tile.tif`, `quad-tile.tif`) are tiled
layout which libtiff detects by the presence of TileWidth/TileHeight
tags. We would detect that by chunks encoded via TileOffsets and
TileByteLengths tags. However the images encoded their chunk data into
the StripOffsets tag; additionally they contain a RowsPerStrip value
anyways.
Tests disabled as this is to be resolved in a separate issue (#338) with
a decision on treatment of this situation (strictness setting or copying
libtiff, also error late for mismatched lengths).
aarshivv