Fix incorrect RLE4 padding checking#50
Conversation
rfuest
left a comment
There was a problem hiding this comment.
Thanks for the PR. The fix itself looks good, but I would like to change a few details.
Co-authored-by: Ralf Fuest <mail@rfuest.de>
|
Just for your information, is stored as Tests pass when fix is applied, and fail when there is old code, so I think test itself successes at detecting the issue, even though I am not sure what is going on with that |
If the bytes are laid out as |
Thank you for helping out with tinybmp development! Please:
CHANGELOG.mdentry in the Unreleased section under the appropriate heading (Added, Fixed, etc) if your changes affect the public APIrustfmton the projectjust build(Linux/macOS only) and make sure it passes. If you use Windows, check that CI passes once you've opened the PR. - Some unrelated to PR error ocured with docsPR description
GIMP can open
bmpthat is added in tests.To explain, the bug, let's look at example:
We want to encode 4 bit colors "0, 1, 2". Spec says, absolute (in terms
tinybmpcode uses) offsets should be padded to 16bit offset. When we encode "0, 1, 2" we see:00 03 01 20. This is aligned, so no padding. Whattinybmpdoes?(len >> 1) % 2 != 0, which yields that there is padding.Specification: https://gibberlings3.github.io/iesdp/file_formats/ie_formats/bmp.htm#Raster4RLE, at "Raster Data compression for 4bit / 16 color images: