jiayuasu commented on PR #3108:
URL: https://github.com/apache/sedona/pull/3108#issuecomment-5077227463
Confirmed and fixed in 9553cc6. JDK 17 returns `[154, 188, 222, 248]`, the
port returned `[154, 188, 222, 0]`.
Correction to my previous comment first: the claim that the 1004-case sweep
covered unaligned data bit offsets was wrong. Its offsets were `{0, numBits, 3
* numBits, size, size + numBits}`, every one of them a multiple of `num_bits`,
so it never built a pixel straddling two samples. The sweep could not have
caught this, and I should not have described it as covering unaligned offsets.
Root cause is narrower than the shift distance alone. Java reads a sample
through `DataBuffer.getElem()`, which returns a signed `int`, then applies
`>>`: an arithmetic shift whose distance an `int` shift takes modulo 32. So the
-4 distance becomes 28 and the sample's top bits move down, sign extended. The
port shifted an unsigned array by a negative count, which numpy zeroes. Samples
are now read as `int32` and shifted by `shifts & 31`, which is Java's width and
Java's masking.
It is not only about the sign bit, so I added both variants as regression
cases: the same layout over `{0x12345678, 0}` reads `[35, 69, 103, 1]` in Java,
and the last pixel was `0` here too. Test is
`test_multi_pixel_packed_pixel_straddling_two_samples`, parameterized over both
banks.
Keeping the offsets in scope rather than narrowing the claim, since the
reader has to handle whatever a serialized Java raster contains. The sweep now
enumerates every `data_bit_offset` from 0 to two samples wide instead of a
handful:
| | layouts | mismatched vs java.awt.image |
|---|---|---|
| master | 7580 | 5295 |
| previous head 642de29 | 7580 | 1291 |
| this head 9553cc6 | 7580 | 0 |
Verified on numpy 1.26.4 and 2.5.1 with numpy warnings raised as errors. The
unit tests are at 22 cases, 21 of which fail without this branch.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
