- Follow the best practices of https://reuse.software/ to ensure BSD-3 licence is correctly applied.
- Add a badge to README.md
- Note: remove arm build as the CI pipeline is broken for this architecture
Fuzzing testing of the C# implementation found a scenario that would cause an endless loop during decoding. This defect was also present in the C++ implementation.
This condition was tested with an ASSERT. Using an ASSERT is fine when encoding, but an explicit check is needed when decoding as the input data is in that case untrusted.
Add an additional method for advanced encodings scenarios. This methods allow to encode components with different
coding parameters like: near lossless, jpeg-ls preset coding parameters or scans with different interleave modes.
Extend the decoder to also be able to decode scans with different interleave modes.
2 components in interleave mode none was already supported. But the options line and sample were not implemented.
Add these 2 options to support all interleave options.
Section ISO/IEC 14495-1, C.2.6 specifies that JPEG-LS allows DNL segments with a length between 4 and 6 bytes. Update the code to handle these DNL segments.
DNL markers are part of the official JPEG-LS standard (but almost never used). Add support to scan the buffer for this
marker segment if the height is zero.
By design CharLS itself will never write DNL marker segment as it always knows the height of the image before it writes the SOF marker segment.
The main purpose of golomb_code_match is to see if there is a precomputed match which allows to just skip the bytes.
Rename the struct to make it clear it is not the actual glomb code itself.
Update the golomb_code_match struct back into a POD. The Windows x64 ABI cannot return non-POD structs in a single register even when the would fit.
The JPEG-LS standard defines 3 compressed data formats. Only the interchange format (the most common) can normally be decoded.
Add a method to allow application code to retrieve the data format of the JPEG-LS stream. This allows an application to decide if it want to display the image
or process it differently.
* Replace functors with function pointers during decoding
The functors were constructed on the heap and the actual implemenation was called using a virtual method call.
The main advantage of a functor (insert inline) could not be leveraged.
As a first step replace these functors with basic function pointers. It replaces a virtual call to a member function with a
function pointer call to a static method (no need to pass this pointer).
* Rename process_decoded_line.hpp in copy_from_line_buffer.hpp
* Replace functors with function pointers during encoding
The functors were constructed on the heap and the actual implementation was called using a virtual method call.
The main advantage of a functor (insert inline) could not be leveraged.
As a first step replace these functors with basic function pointers. It replaces a virtual call to a member function with a
function pointer call to a static method (no need to pass this pointer).
* Rename process_encoded_line.hpp to copy_to_line_buffer.hpp
By design the benchmark project is not build as it relies on Google Benchmark that is retrieved using vcpkg.
Vcpkg is now part of Visual Studio 2022, so building with VS 2022 works.
One of the build steps of the CI pipeline build CharLS however with VS 2019 to ensure that VS 2019 still can be used. Enabled benchmark in the solution file for x86 and X64 would break VS 2019.
ARM64 build are only support in VS 2022, so enabling that version doesn't break VS 2019.
To make it more clear to users and tooling that the project is a C++ project use the extension .hpp for pure C++ headers.
Add a new public header file charls.hpp. External C++ projects should this header file, C projects should still use charls.h.
Group the error IDs in errors that cannot be prevented and can be reported at runtime and in a set of errors that can be prevented.
Note 1: the error destination_too_small is considerd a runtime failure, but can in many cases be prevented.
Note 2: unexpected exceptions will now trigger a call to std::terminate (improved crash dumps)
The line buffer is 2 pixels longer then required to make is easier to encode pixels on the edges. The start of the pointers was set to the first real pixel.
This caused the problem that negative indexes needed to be used in the code, which looks incorrect at first sight and makes the code harder to port.
The same was already done for the decoding process.
The line buffer is 2 pixels longer then required to make is easier to decode pixels on the edges. The start of the pointers was set to the first real pixel.
This caused the problem that negative indexes needed to be used in the code, which looks incorrect at first sight and makes the code harder to port.
- Move constant values that are only used once to the method that uses these constant values (reduces scope)
- Rename context_regular_mode to regular_mode_context and context_run_mode to run_mode_context
- Reduce the line buffer from 4 extra items to 2 (2 are needed for the borders).
- Replace dynamic run_index buffer with static buffer (max size is only 4 items)
* Add support to write mapping tables to the JPEG byte stream.
* Add API method to set the table ID for a component
* Add method to create JPEG-LS file with mapping tables only.
* Add support to read mapping tables
* Parse table-ids from the scan segment
* Extend API of charls_decoder_get_mapping_table_index to return -1 if index is not found
* Add support to read mapping table continuation segments
* Document new API methods
* Add sample image from appendix H.4.5 "Example of a palletised image" / Figure H.10 to unit test
* Update the get_mapping_table API to include size of the buffer
Background: a pixel consist of 1 or more samples. (RGB has 3 samples for example).
CharLS uses as SampleType a byte (uint8_t) or a 16 bit byte (uint16_t)
The HP color transformations apply only to RGB colors in sample and line mode.
- Add more unit tests
- Remove not used transformations for quad (4 component pixels)
- Remove not needed color transformations
Invalid input data may trigger an invalid read.
This scenario will be hit for invalid input data that completes
a scan but hasn't a marker start byte at the expected position.
The current algorithm will add additional bits to the cache, but this requires an additional check for the position.
Note: found with LibFuzzer
It is beter to only use the major version to make it possible to automatically pickup the latest version (instead of a specific tag). Upgrades of major versions are done useing dependabot
