Open zerkms opened 4 years ago
Change https://golang.org/cl/211237 mentions this issue: go.image/tiff: fix for decoding grayscale tiled images
/cc @nigeltao
/cc @bsiegert
Hey team, any chance this to be dragged forward any time soon? It's a pretty significant bug, yet with a simple fix.
I dropped some review comments on https://go-review.googlesource.com/c/image/+/211237
Sorry for the late reply.
Given how the progress ended last year, and given I want to invest some time into finally having it merging now: does anyone from Go team have understanding of what exactly I need to do to have it merged?
Okay, I jumped into the code once again, and intermediate results/discoveries:
mRGB
16bpp also affected, the same trivial fixmRGB
(non 16bpp) is not affected, because offsets are calculated before each stride iterationmPaletted
is affected, the same trivial fixmNRGBA
16bpp probably is affected, but I don't have an image to testmRGBA
16bpp probably is affected, but I don't have an image to testmNRGBA
(non 16bpp) - most likely not affected, cannot verify without imagemRGBA
(non 16bpp) - most likely not affected, cannot verify without imageTo summarise: I can fix 3 of them, and I need mNRGBA
and mRGBA
encoded images to fix the rest.
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
When you decode tiled tiff grayscale image you may find that tiles placed on the image boundary (right) are decoded incorrectly.
It happens because the tiff file contains the complete tile compressed, while the loop iterates only over the part of it that fits the image boundary:
So if you read pixels from the non-complete tiles (from the right edge) all lines but the first one would contain real data mixed with garbage (bits from outside the image boundary).
What did you expect to see?
What did you see instead?