You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The decoder now treats non-interleaved streams as blocks
In the standard, section 4.8.2 it states:
> Minimum Coded Unit
> [...] If the compressed image data is non-interleaved, the MCU is
> defined to be one data unit [...] If the compressed data is
> interleaved, the MCU contains one or more data units from each
> component.
Previously, things were processed from stream as if they were always
batched group size. This typically doesn't cause a problem, but some
progressive jpegs perform additional adjustment passes on individual
components. In events where (for example) a component has a 2x2
sampling factor, this meant that things would be processed incorrectly.
The offsets were correct but, for example in #173, an EOB for 240
blocks would be exhausted after only a quarter of the (incorrectly)
expected MCUs were complete. This meant that it would continue to read
from the stream as it thought the EOB was over. In this case, a reset
marker was incorrectly consumed and things went off the rails shortly
after.
Now a distinction is made between MCU sizes in interleaved &
non-interleaved streams. Most of the time, in non-interleaved streams
this manifests as MCUs being treated as blocks instead (and adjusting
the indices involved in that).
One complication is with how the worker thread pool currently accepts
'MCU rows' from the scan; always in batched size. So, while the stream
treats MCUs as blocks, the worker threads are still looking for
full-sized units. This means some care must be taken to correctly time
when to send the data over to the worker threads.
The final change undertaken was to move the reset check logic to the
top of the processing loop; this simplified some of the logic and
ensured that interleaved & non-interleaved streams were treated
correctly.
This also (I believe), addresses the concerns of #89.
0 commit comments