Skip to content

V4 TIFF : Allow additional and undefined extra samples #2941

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 12, 2025

Conversation

JimBobSquarePants
Copy link
Member

Prerequisites

  • I have written a descriptive pull-request title
  • I have verified that there are no overlapping pull-requests open
  • I have verified that I am following the existing coding patterns and practice as demonstrated in the repository. These follow strict Stylecop rules 👮.
  • I have provided test coverage for my change (where applicable)

Description

See #2408

This PR removes explicit validation checks that disallow TIFF files with unspecified or multiple TiffExtraSampleType values. These checks are unnecessary and overly restrictive.

Rationale

  1. Decoder logic already defends against unsupported configurations
    The decoding path only processes known and supported sample layouts (e.g., RGB + unassociated alpha). Unsupported layouts naturally fail at the point of use without requiring upfront rejection.

  2. Unspecified extra samples cannot be meaningfully decoded
    According to the TIFF specification, TiffExtraSampleType.UnspecifiedData provides no semantic meaning. There is no way to determine how such channels should be interpreted. Since these channels carry no defined role, the decoder either discards them or ignores them during processing. Explicit rejection is redundant.

  3. Improved compatibility with real-world files
    TIFFs produced by some tools (e.g., legacy or proprietary software) may include extra channels with incomplete or non-standard metadata. Allowing the decoder to handle these cases gracefully increases format compatibility without compromising decoder integrity.

Notes

  • This aligns with how libtiff handles ambiguous or malformed ExtraSamples, such as the CorelDRAW-specific 999 value.
    See libtiff 3.9.0beta release
  • Files with unsupported layouts will still fail safely at the decoding stage.

Copy link

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR relaxes restrictions on TIFF files with additional or undefined extra samples, enhancing compatibility with real-world files.

  • Added a new test image and corresponding test reference for TIFFs with unspecified extra samples.
  • Updated the TiffExtraSampleType enum to include a CorelDRAW-specific value and modified the decoder options parser to patch this value for compatibility.

Reviewed Changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

Show a summary per file
File Description
tests/Images/Input/Tiff/Issues/ExtraSamplesUnspecified.tif New test image added to support the updated extra samples behavior.
tests/ImageSharp.Tests/TestImages.cs Constant updated to include the new test image path.
tests/ImageSharp.Tests/Formats/Tiff/TiffDecoderTests.cs New test case added for verifying decoding of TIFF files with unspecified extra samples.
src/ImageSharp/Formats/Tiff/TiffExtraSampleType.cs Enum updated to include CorelDrawUnassociatedAlphaData with explanatory comments.
src/ImageSharp/Formats/Tiff/TiffDecoderOptionsParser.cs Decoder options logic updated to support the new extra sample type and patch incompatible values.

@JimBobSquarePants JimBobSquarePants merged commit a87f5ef into main Jun 12, 2025
22 checks passed
@JimBobSquarePants JimBobSquarePants deleted the js/v4-tiff-extra-samples branch June 12, 2025 12:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant