Fixed invalid jpeg buffer width compliment for scalar color converters #2427
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Prerequisites
Description
Partially fixes #2414 for jpeg and tiff with jpeg compressions tests for scalar path. According to #2414 (comment) we have some more failing tests for GIF and PNG.
Problem was with how jpeg decoder determined buffer size compliment for color converters as those required buffer size to aligned to their batch size, e.g. for avx with batch size 8 buffer size should be divisible by 8, 204 => 208. For scalar encoders any buffer size is complient as any number is divisible by 1 without a remainder.
Decoder was adding
(batch_size - remainder)
to the buffer size which led to extra 1 pixel for scalar implementations- that's why decoded image had this diagonal color shift:This PR is not covered by tests as I want us to discuss possible solutions of how actually we should cover all scalar paths. I think solution in #2414 (comment) could be quite handy