Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Feature request: support for restart markers #92

Closed
akaraivanov opened this issue Aug 31, 2021 · 9 comments
Closed

Feature request: support for restart markers #92

akaraivanov opened this issue Aug 31, 2021 · 9 comments
Labels
enhancement
Milestone
2.3.0

Comments

@akaraivanov
Copy link

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.
@tsondergaard
Copy link

Related to #88.

@vbaderks
Copy link
Contributor

vbaderks commented Sep 1, 2021

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.

@vbaderks vbaderks added this to the 2.3.0 milestone Sep 1, 2021
@akaraivanov
Copy link
Author

akaraivanov commented Sep 1, 2021 •
edited
Loading

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.
IMG00000 44

@vbaderks
Copy link
Contributor

vbaderks commented Sep 3, 2021

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.

@vbaderks
Copy link
Contributor

vbaderks commented Sep 3, 2021

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.

@vbaderks
Copy link
Contributor

Support to decode restart markers has been added with commit cb44fab

@tsondergaard
Copy link

Thanks @vbaderks, this is really great! When do you anticipate making a release of charls that includes this?

@vbaderks
Copy link
Contributor

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?

@tsondergaard
Copy link

A release would be convenient for us, but not urgent. We can wait. Thanks a lot for your work on this!

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue Nov 14, 2022
Update graphics/charls to version 2.3.4
33ab676 
Changes from CHANGELOG.md:

# Change Log
## [2.3.4] - 2021-2-12

### Changed

- Replaced legacy test images.

## [2.3.3] - 2021-2-5

### Fixed

- Fixed [#167](team-charls/charls#167),
  Decoding\Encoding fails on IBM s390x CPU (Big Endian architecture).

## [2.3.2] - 2021-1-29

### Fixed

- Fixed team-charls/charls#160,
  warning: cast from 'unsigned char*' to 'uint16_t*'
  increases required alignment of target type.
- Fixed team-charls/charls#161 ,
  warning: useless cast to type 'size_t' {aka 'unsigned int'}
  [-Wuseless-cast].

### Changed

- Updates to the CMakeLists.txt for Unix builds (except macOS)
  to hide more symbols from the shared library.
- C++14 is now the minimum version instead of explicitly required.
  This allows consuming applications more flexibility.
  Typically CMake will select the latest C++ standard version that
  the used C++ compiler supports.

## [2.3.1] - 2021-1-25

### Fixed

- Fixed team-charls/charls#155 ,
  charls::jpegls_decoder::decode: 2 overloads have similar conversions
  in v2.3.0

## [2.3.0] - 2022-1-24

### Added

- The encoder API has been extended with a rewind method that can be
  used to re-use a configured encoder to encode multiple images in a loop.
- Added support to decode JPEG-LS images that use restart markers
  team-charls/charls#92 .
- Added support to write and read comment (COM) segments
  team-charls/charls#113 .
- Added support to encode/decode oversized images
  (width or height larger then 65535).
- Extended the validation of the encoded JPEG-LS byte stream during decoding.
- Added support to encode JPEG-LS images with:
  - The option to ensure the output stream has an even size.
  - The option to write the CharLS version number as a comment (COM segment)
    to the output stream.
  - The option to write the coding parameters to the output stream if
    the bits per pixel are larger then 12 (enabled by default).
- Usage of compiler specific attributes on the public API as replacement for
  ``[[nodiscard]]`` (which is a C++17 feature).

### Fixed

- Fixed team-charls/charls#84 ,
  Default preset coding parameters not computed for unset values.
- Fixed team-charls/charls#102 ,
  CMake find_package(charls 2.2.0 REQUIRED) not working.

### Changed

- CMakeSettings.json has been replaced with CMakePresets.json.
- Non default coding parameters are explicitly stored in
  the output stream during encoding.
- GCC shared library release builds are now using LTO
  (Link Time Optimization).
- Some functions use compiler intrinsics for slightly better performance.

## [2.2.1] - 2022-2-3

### Fixed

- Backport of fix for team-charls/charls#167 ,
  Decoding\Encoding fails on IBM s390x CPU (Big Endian architecture).
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
2.3.0
Development

No branches or pull requests
3 participants
@tsondergaard @vbaderks @akaraivanov