Replace chunked scratch-buffer approach with direct indexed writes
into the pre-allocated output. Simpler and faster in practice.
Co-Authored-By: Claude <noreply@anthropic.com>
Replace single-byte pushes with chunk-based processing: pre-allocate
zeroed output, shuffle 4 values at a time into a stack buffer, then
copy_from_slice each byte lane into the output.
Co-Authored-By: Claude <noreply@anthropic.com>
Process the difference step in reverse 16-byte chunks, reading both
curr and prev into local arrays before writing. This makes all 16
subtractions independent, enabling autovectorization (confirmed with
SSE2: movdqu + psubb).
Co-Authored-By: Claude <noreply@anthropic.com>
Replace the two near-identical floating-point predictor encoding
functions with a single fp_predict! macro parameterized on the float
type, using core::mem::size_of to derive the byte size.
Co-Authored-By: Claude <noreply@anthropic.com>
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>
Do we even want to error early here? This isn't exactly fatal to reading
the image it is a only nuisance. It becomes crucial only when we are at
the point of reading all the tiles themselves.
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).
This complements the entry API of the encoder with the byte slice based
method. Note we don't provide it for writing raw data, here a
`std::io::Write` would be more appropriate and we should not attempt to
make it `write_all`, nor compress. You'd get all the benefits of the
other API through `[u8]: TiffValue` since that interface is otherwise
type agnostic and `u8` specifically is endian agnostic.
We have not released this yet, let's align these names before it is too
late. The decoder adopted the `_buf` suffix and I find it more
convincing than the more generic `_value` (that also confusingly shares
it with `TiffValue`).
Implement the encoder's `TiffValue` trait for the tags commonly defined
and represented as separate types in our own code. We don't tie the
tag for an entry of these to the value type (yet). This lets us keep the
trait exactly as-is and we avoid unnecessary churn. We can always add a
separate trait on top.
Seems they were introduced with BigTiff but since the enumeration of the
decoder had no obligation of introducing discriminant values the list
was not cross-referenced to libtiff. Hence, some rational types exist
with no basis in decoding.
