Conversation
In particular we avoid mistaking the absence of this tag for an absence of subsampling. The specification instead requires it to mean half the samples in both directions—a mode that we do not support yet. Instead of returning erroneous samples or an error in the data stream (which would appear too short) we return an error when asked to layout the read buffer for these images.
I didn't realize we support this in a slightly weird manner where the tag is completely ignored and zune-jpeg performs the upsampling as indicated in the JPEG stream. This is a recurring problem with the compression scheme and tags in TIFF. In the end, decoder can only handle the data as indicated by the JPEG steam and while the specification requires the tags to be consistent with the underlying data, sometimes they are not. The useful fallback is of course to ignore the tag. Ignoring the tag of course buts us in a weird spot for zero-copy decoding since the buffer indication to the caller will be incorrect. For now, maybe the best way of treating subsampling is to upsample all the cases when we add support.
fintelia
approved these changes
Jan 5, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Note that in the decoder we error late if the information in the tag has at least the right type and is plausible. We only have a problem supporting the buffer layout that would be calculated, iterating over the image itself leaves us in a fully consistent state otherwise.
Also fixes a bug in the encoder where we apparently already have support. The default value for the tag, i.e. its interpretation if absent, is
(2, 2), which implies that some form of subsampling should be used. Since the samples we encode are not subsampled (we explicitly enforce the sample count of a4:4:4layout) the tag must be present and specify this. Here's two images that show the difference:ycbcr-correct.tiff
ycbcr-wrong.tiff
Note that the intended data is a full
256×256grid going from R,G=0 to R,G=255 in X and Y orientation respectively with blue being the middle point between the other colors. That is, the top-left corner must be full black and the bottom-right must be full white. For the second image the samples are interpreted incorrectly and we get a mash. The first image is the state after this PR.