Feature request: support for restart markers
akaraivanov opened this issue · 9 comments
I'd like to request a support for restart markers (JPEG_DRI and JPEG_RSTm) in decoder only.
Motivation: even though this feature of the standard is rarely used, we do encounter images in the world that utilize it. Most likely it is being used to facilitate parallelism during the encoding.
Related to #88.
Interesting to hear images exists that have restart markers.
It is no problem to add support for it during decoding. I might also add some support for it during encoding (makes code easier to test).
If you have images with restart markers that you can share, that would be great.
Here is a sample image.
I wonder if we'll need support for DNL too (provided sample does not use DNL). I am not sure how is size of a MCU defined. Is it what Appending B says about it, or it is also determined by the encoder.
Support for DNL (Define Number of Lines) would be an independent feature.
DNL allows the encoder to leave the number of lines unknown until after the first scan.
This makes decoding much more complicated. As the client code needs to allocate the destination buffer the number of lines must be known to compute the size of this buffer and before decoding can be started. A solution would be scan the encoded pixel data for the DNL segment, which is however slower then just reading this info from the frame header.
I have created branch restart-markers to track\share the work that needs to be done for this feature. It might be possible that a force push is needed to merge\update commits to get a clean history to be able to merge into master.
Thanks @vbaderks, this is really great! When do you anticipate making a release of charls that includes this?
The 2.3 release is planned for the end of this year. There is some overhead involved in making a release and updating all the downstream packages. There are still some issues I want to close and things to add before the 2.3 release.
Would there be an urgent need for a release?
A release would be convenient for us, but not urgent. We can wait. Thanks a lot for your work on this!