Incompatibilty with non-interleaved JPEG

[nolmoonen]

JPEG files with non-interleaved scans are not handled correctly:

1. Lepton files produced by Dropbox' implementation cannot be decoded correctly by this project.
2. Dropbox' implementation cannot decode Lepton files produced by this project.

To test this, I took cathedral.ppm from https://imagecompression.info/test_images/ and compressed with with cjpeg from libjpeg-turbo (e.g. the libjpeg-turbo-progs package on Ubuntu):

# scan.txt contains "0;1;2;", see https://github.com/libjpeg-turbo/libjpeg-turbo/blob/main/doc/wizard.txt
cjpeg -optimize -outfile cathedral.jpg -scans scan.txt cathedral.ppm

cathedral.jpg

I had to zip the Lepton files otherwise I couldn't upload them to GitHub.

I used the current main branch of this project (adf4f4a).

Compressed with Dropbox's implementation (./lepton cathedral.jpg && mv cathedral.lep cathedral_db.lep): cathedral_db.zip.

Decompressing with this project (./lepton_jpeg_util cathedral_db.lep cathedral_db_ms.jpg) gives a greyscale JPEG:
cathedral_db_ms.jpg. It seems that only the first scan is decoded (can be observed by trying some different scan order, e.g. 2;0;1;).

Compressing with this project (./lepton_jpeg_util cathedral.jpg cathedral_ms.lep): cathedral_ms.zip

Decompressing with Dropbox' implementation (./lepton cathedral_ms.lep) reports ASSERTION_FAILURE and fails.

Note that compression and decompression (roundtripping/validating) with the same project does work correctly.

I haven't looked myself in how the produced Lepton files differ, but I assume that the preferred option is to produce the Lepton file similarly to how Dropbox' implementation does it. Otherwise, the Lepton "specification" is expanded and a Lepton file in the wild has two possible ways of decoding. From my experience, non-interleaved JPEG files aren't very common but I suspect that this will appear more often than the math overflow in the Dropbox implementation.

[mcroomp]

I think this fixes it #178

[nolmoonen]

I've check out the branch and can confirm that sequential JPEG files with multiple scans that are compressed by Dropbox' implementation can now successfully be decoded by this project. However, this project can no longer compress such files. E.g. compressing the cathedral.jpg linked above gives:

2026-01-23T13:01:52.859Z INFO  [lepton_jpeg::structs::lepton_file_writer] compressing to Lepton format
2026-01-23T13:01:52.875Z ERROR [lepton_jpeg_util] error UnsupportedJpeg: progressive encoding range was invalid 0 to 63
 at lib/src/jpeg/jpeg_read.rs:439:24
 at lib/src/jpeg/jpeg_read.rs:223:85
 at lib/src/structs/lepton_file_writer.rs:85:81
error code: UnsupportedJpeg 42 progressive encoding range was invalid 0 to 63
 at lib/src/jpeg/jpeg_read.rs:439:24
 at lib/src/jpeg/jpeg_read.rs:223:85
 at lib/src/structs/lepton_file_writer.rs:85:81

[mcroomp]

Thanks, yes that is true. I fixed it in #179 where I still need to be able to read the LEP files that were created by the bad versions.

[nolmoonen]

Ah, okay. I just tried #179 (1570c2b) and it works for me to decode Leptons produced by Dropbox' implementation but I get errors the other way around. I.e. decoding Leptons produced by this project using Dropbox' implementation. For instance on the cathedral.jpg image linked here:

$ ./lepton_jpeg_util cathedral.jpg cathedral.jpg.lep
2026-01-23T14:21:39.753Z INFO  [lepton_jpeg::structs::lepton_file_writer] compressing to Lepton format
2026-01-23T14:21:39.774Z INFO  [lepton_jpeg::structs::lepton_file_writer] Number of threads: 8
2026-01-23T14:21:39.790Z INFO  [lepton_jpeg::structs::lepton_file_writer] worker threads 84ms of CPU time in 15ms of wall time
2026-01-23T14:21:39.790Z INFO  [lepton_jpeg::structs::lepton_file_writer] decompressing to verify contents
2026-01-23T14:21:39.823Z INFO  [lepton_jpeg_util] compressed input 690601, output 550255 bytes (compression = 25.5%)
2026-01-23T14:21:39.823Z INFO  [lepton_jpeg_util] Main thread CPU: 70ms, Worker thread CPU: 183 ms, walltime: 70 ms
$ ./lepton cathedral.jpg.lep 
lepton v1.0-1.2.1-194-gf34c7f4
Assert Failed: outth.num_overhang_bits == thread_handoffs[logical_thread_id + 1].num_overhang_bits at (src/lepton/recoder.cc:635)
ASSERTION_FAILURE
Assert Failed: memcmp(outth.last_dc.begin(), thread_handoffs[logical_thread_id + 1].last_dc.begin(), sizeof(outth.last_dc)) == 0 at (src/lepton/recoder.cc:639)
ASSERTION_FAILURE
Assert Failed: outth.num_overhang_bits == thread_handoffs[logical_thread_id + 1].num_overhang_bits at (src/lepton/recoder.cc:635)
ASSERTION_FAILURE
Assert Failed: outth.num_overhang_bits == thread_handoffs[logical_thread_id + 1].num_overhang_bits at (src/lepton/recoder.cc:635)
ASSERTION_FAILURE
Assert Failed: memcmp(outth.last_dc.begin(), thread_handoffs[logical_thread_id + 1].last_dc.begin(), sizeof(outth.last_dc)) == 0 at (src/lepton/recoder.cc:639)
ASSERTION_FAILURE
Assert Failed: outth.num_overhang_bits == thread_handoffs[logical_thread_id + 1].num_overhang_bits at (src/lepton/recoder.cc:635)
ASSERTION_FAILURE
Assert Failed: outth.num_overhang_bits == thread_handoffs[logical_thread_id + 1].num_overhang_bits at (src/lepton/recoder.cc:635)
ASSERTION_FAILURE
1: Worker thread out of memory.
THREAD_PROTOCOL_ERROR

[mcroomp]

yeah doesn't look quite as easy as i thought... i'll put it into its own PR

[nolmoonen]

Alright, thank you for your continued efforts!