Repository navigation
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
With both
set_optimized_huffman_tables(true)andset_restart_interval(n), the encoder can write a JPEG that doesn't decode.optimize_huffman_tablecounts the DC differences of each component's blocks as if the prediction ran through the whole scan. When the blocks are written, though, each restart marker resets the prediction to 0, so the first DC difference after a marker is the DC value itself. That difference often falls in a category the optimized table has no code for.get_for_valuethen returns a zero-length code: release builds write nothing for the symbol, and debug builds hit thedebug_assert!inhuffman.rs.For example, I encoded a 17x1 image with RGB, quality 95,
F_1_1, a restart interval of 1 and optimized tables:djpegandjpeginfo -creport "Corrupt JPEG data: 7 extraneous bytes before marker 0xd1".I tried every combination of Luma and RGB; 17x1, 300x3, 37x29 and 64x64; restart intervals 0, 1, 2, 3 and 7; optimized tables on and off; progressive on and off; and
F_1_1andF_2_2.jpeginfo -c, and every image decodes within 1 dB of the same image encoded without a restart interval.The DC statistics now reset the prediction at the same blocks where
encode_image_sequentialand the DC scan ofencode_image_progressivewrite a restart marker. With optimized tables, every scan is non-interleaved, so that is everyrestart_intervalblocks of a component. AC statistics don't depend on the prediction and are unchanged.Tests:
test_restart_interval_optimized(RGB, interval 32) andtest_restart_interval_optimized_progressive(grayscale, interval 1). Both fail onmainat thedebug_assert!inhuffman.rs.cargo testpasses with the default features,--features simd,--features use_wideand--no-default-features --tests.cargo fmt -- --checkis clean. The clippy warnings are the ones already onmain.