The block coder should be usable without pulling in the rest of OpenJPH

[chafey]

It should be possible to use the block coder without pulling in the rest of OpenJPH. That would make using the block coder with out libraries (grok, OpenJPEG, etc) easier

This can be done by creating a new CMake library target "htj2kblockcoder" that OpenJPH (and other libraries) can depend on

[palemieux]

Any suggested API to the block coder?

[chafey]

Haven't thought about it yet, but it does have an api already:

https://github.com/aous72/OpenJPH/blob/master/src/core/coding/ojph_block_decoder.h#L53 https://github.com/aous72/OpenJPH/blob/master/src/core/coding/ojph_block_encoder.h#L55

If you take that as a starting point, a few things I would consider:

1. Research C++ ABI Compatibility best practices
2. Switch from ojph specific types (ui8, ui32) to standard types (uint8_t, uint32_t)
3. Wrap related parameters into a struct. One for input, one for output?
4. Enable C based integrations for other languages - (extern "c" linkage, return error not throw exception, ?)
5. Expose a single api for decode and encode with a parameter to allow selecting the code path (non accelerated, SSE3, WASM, autoselect?). Right now the caller has to dispatch requiring a new api be added for each code path which makes maintenance/integration more difficult

[palemieux]

@rouault Thoughts on an API to the HT block coder that would make it easier to maintain/integrate with OpenJPEG and other projects?

[chafey]

@boxerab your thoughts?

[aous72]

It would be interesting to see @rouault thoughts on this.

But I remember one difficulty I faced with OpenJPEG is the requirement that the code compiles with Visual Studio 2010 (or was it an older version?). That required me to modify the code significantly -- put all variable declarations at the top of function and so on. I suspect this is still a requirement. Also OpenJPEG has support for up to SSE2. To get good benefit from SIMD instructions for block decoding, the block coder needs SSSE3 -- SEE2 does not have many of the needed instructions. Doed OpenJPEG wants this?

Other implementation may need to have some stub code (I think CS call it facade) to interface with the library -- OpenJPH block decoder pushes all the data to the MSBs, while OpenJPEG (and FFmpeg it think) push the data one location up, using the LSB as the center of the dequantization bin -- data is shifted by different amounts.

[rouault]

I faced with OpenJPEG is the requirement that the code compiles with Visual Studio 2010 (or was it an older version?).

This is more than our CI still sticks to that and I've found little time/motivation to update to something more modern, but that's clearly irrelevant nowadays. VS2019 / C99 support should be our baseline nowadays.

Also OpenJPEG has support for up to SSE2.

The base x86_64 version should stick with that. But we have a few AVX2 compile-time code paths in the discrete wavelet transforms. Ideally we should have dynamic SIMD selection.

Probably the most blocking issue is that OpenJPEG is still a C-only lib. Personally I would have nothing against internals to be partly C++ while keeping a user facing C API. Should be discussed with the rest of the OpenJPEG community.