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.
- sonar.cfamily.cache.enabled is obsolete: remove it
- Only analyze the source code of the library
- Exclude the template source code file scan_decoder_impl and scan_encoder_imp. SonarCloud has problems to see that these are different files and cannot be merged.
When encoding images ensure that only the valid bits are used. For bit size 16 and 8 there is no change and memcpy will be used.
Encoding with masking is not measurable slower.
Setting explicit InlineFunctionExpansion for debug needs to be removed as it prevents debugging. For release mode it is also not needed as MaxSpeed will already enable it.
Mask high input bits during encoding (interleave_mode::sample)
Mask high input bits during encoding
The .NET adapter has been moved to its own repository at https://github.com/team-charls/charls-native-dotnet
The .NET adapter in this repository was for .NET standard 2.0, which has been replaced by .net5.0
Having the .NET adapter in its own repository makes releasing easier and many uses case only require the "pure" C++ native library.
In the BMP file format every row is rounded up to a multiple of 4 bytes. The original sample code was unable to handle it. When using images with a special size (for example 403 * 100) this would cause incorrect converted images.
The C and C++ samples can convert a .bmp file to a .jls encoded file. These samples were missing essential steps to ensure the .jls images look the same as the original .bmp image. This has been corrected with:
- Pixels in a .bmp file are stored as Blue\Green\Red, JPEG-LS requires these to be in the format Red\Green\Blue
- The rows in a .bmp file are stored bottom up, JPEG-LS expects these files top down
- An additional command line parameter has been added to control which interleave mode to use
Apply the modern way of documenting the used license, by referencing a SPDX Unique License Identifier in the source code files.
Note: From the legal point of view, this commit is only a change to the textual representation of the license information, but in no way any change to the actual license terms. With this commit applied, all files will still be licensed under the same terms they were before.
The current C API prevents adding new features and the introduction of an object oriented C++ interface. Every change results directly in a ABI break. To prevent this a new C API is introduced that is easier to extend and to maintain. On top of this API are 2 C++ classes: jpeg_encoder and jpeg_decoder to encode and decode JPEG-LS files.
This commit comes also with the following changes:
- Updated .clang-format
- Switch to Visual Studio 2019 for the CI build pipeline
- Support for reading and writing SPIFF header
- Incomplete support for JFIF header has been removed
- Extended unit test coverage
CharLS is a C++ based implementation, but provides a C interface for a stable ABI. As an initial step, create a C++ sample application to protoype a header only C++ API.
Note: it is not possible to use .NET Core for this unit test project. Only 1 dotnet.exe can be in the path, and while both the x64 and x86 version can be installed, only 1 can be active. This makes it impossible to test both the x64 and the x86 build.
Other changes:
- Remove JpegLSBitmapDecoder (unsupported by .NET Core)
- Rename solution name from Win32 to x86 to ensure CI build works.
