Splat adam7 interlacing

[thirumurugan-git]

As a follow-up to this issue in Chromium, I created a corresponding PR in image-png.

CC: @anforowicz

[thirumurugan-git]

@anforowicz Please review this PR and share your suggestions on the TODOs.

[anforowicz]

Thanks for the PR!

[kornelski]

I think filling the image pixels completely is the expected behavior, so it would be nice to make this easy/default, but I'm not sure how such thing could be integrated with the library API.

Doing this in expand_interlaced_row would needlessly overdraw pixels when decoding multiple passes at once. So even though standalone function doesn't feel like the most elegant solution to me, I don't have a suggestion for anything better.

[anforowicz]

@kornelski and/or @fintelia - can you take another look please?

[fintelia]

I'm suspicious that this might overflow on 32-bit systems. The problem isn't so much that there's likely to be many valid images more than 500 million pixels wide, but rather that fuzzers are really good at figuring out how to populate header fields so that the code reaches the overflow before noticing that the rest of the file is corrupt.

(Looking now, I think the existing expand_adam7_bits code might have the same issue)

[fintelia]

I think this can use the div_ceil method

[fintelia]

Rust convention is to mostly avoid abbreviations in variable names. So for instance, sample_offset rather than samp_off

[fintelia]

I think this whole function can be simplified a bunch. If I'm not missing something, should be a matter of...

let pass = PASS_CONSTANTS[self.current_pass as usize - 1];

self.line_width = (self.width - pass.samp_off).div_ceil(pass.samp_mul);
self.lines = (self.width - pass.line_off).div_ceil(pass.line_mul);
self.line = 0;

(And making the constants u32 rather than usize)

[thirumurugan-git]

@fintelia I've made the necessary changes for the splat expand pass. However, updating the parameter types as discussed, like changing u32 for image width/height and using u64 for byte handling, would require refactoring the existing codebase, including tests. Since that would introduce significant changes beyond the scope of this feature, I’d prefer not to include that refactoring here.

Would it make sense to create a separate issue to track the type changes and have further discussions around using u32::div_ceil or u64::div_ceil there? Let me know your thoughts.

[fintelia]

I'm OK with deferring changes to other parts of the codebase, but I do want to make sure that this PR doesn't introduce new integer overflow bugs. At a minimum, we absolutely cannot do img.len() * 8 which will overflow even on an RGB8 16K x 16K image (on 32-bit platforms).