JPG always encodes 8x8 pixel blocks. If the input image does not have a width or height that's a multiple of 8, the last column or row is just used multiple times for the remaining pixels of the block. The original code first calculated p (the index into the pixel data) with the "imaginary" row/colum (that might be up to 7 pixels too far into each direction) and then subtracted the necessary amount of bytes it if row >= height or col >= width. That was a bit cryptic (IMHO), and didn't get more readable/obvious when vertical flipping was added - which introduced a bug, by not taking stbi__flip_vertically_on_write into account when adjusting p for row >= height... The code should be more obvious (and less buggy) now. This fixes bug #592master
parent
e6afb9cbae
commit
1ad30e4e77
1 changed files with 8 additions and 6 deletions
Loading…
Reference in New Issue