BUG: Artfiacts when encoding irreversible color images about openjph HOT 12 CLOSED

Thank you Chris.

It is something that I forgot.

In ojph_expand, and in particular in the fileojph_image_io.cpp, I check if sample values are within their legible range, [0, 255] for Lena. If a value is larger, I clip it to 255, and if it is smaller I set it to 0.

The reason why this is not done in the library is that the library should produce the best estimate of the values; these estimates can be used in further processing. Then, before saving the file, the code should check that values are within the legible range.

In my world version, this clipping should ideally be done in javascript in index.html

I love what you have done with the webpage.

Kind regards,
Aous.

from openjph.

I would have to add that something in the library as it stand is not ideal.

In the irreversible path, I convert floats to integers before returning them. A better design is to return them as floats, and let the caller, ojph_expand, convert them to whatever format it wants.

Cheers,
Aous.

from openjph.

In the webpage, the input data is always [0,255] for Lena so I am not sure what additional clipping I can do. The way it works is that I first decode the encoded Lena into an 8 bit RGB buffer. When the user adjusts the quantization slider, I take the 8 bit RGB buffer and feed it back into the library. Since the input data is 8 bit RGB, the data is already [0,255] for each channel. Am I misunderstanding?

BTW- I am also seeing complete image corruption when encoding some of the other DICOM images. I need to investigate further before filing a bug.

from openjph.

Oh I misread - the clipping should be done on the decoded values! I just applied that fix and it solved the problem. THank you!

from openjph.

Follow-up question - do all values need to be clamped regardless of the source image? Is this needed only for irreversible and color 8 bit or does it also apply to reversible grayscale 16 bit?

from openjph.

Nevermind, figured out that clamping is required on all data types via experimentation. This fixes the image corruption issue in some of the other DICOM images I mentioned too

from openjph.

Is it true that clipping is only needed when the image is irreversible? Is there anyway to estimate the precision of the error? I can optimize the decoding if I don't have to clamp so am looking for the logic to do so.

from openjph.

Clipping is needed because quantization changes the original values such that when synthesis is employed, out of range values occur.
For the reversible path, I think, but never tested, clipping is also required if quantization is employed.

I also think that reduced resolutions can create out of range values.

Is there anyway to estimate the precision of the error?
I think you mean the maximum error in order to optimize the decoding.
I am not sure about this, but I do not think there is a way to achieve this.

One thing that you might want to look at is to implement SIMD instructions for WASM. It is supported in Chrome, maybe behind a flag.
https://v8.dev/features/simd
I believe this is similar to SSE2 implementation, so you can adapt my sse2 versions.
This SIMD will eventually be implemented by all browsers.

from openjph.

How can you use quantization and still be reversible?

Regarding SIMD - good to know that OpenJPH doesn't support SIMD - I was hoping this was already implemented and was planning to try it out once I had time. I don't have any need for faster HTJ2K right now so probably won't implement it unless I am super bored lol

from openjph.

How can you use quantization and still be reversible?

I mean the reversible 5/3 wavelet path. I do not have quantization, but this can be added, as you suggested in our talk long ago.

OpenJPH implements SIMD for Intel for colour and wavelet transform and the likes. It does not do that for the block coder/decoder. But for WASM, Intel SIMD must disabled. I was thinking that when SIMD picks up to implement WASM SIMD.

from openjph.

Does HTJ2K support quantizing the reversible path? I assumed it was only available for the irreversible path. Note that EMSCRIPTEN failed to compile when I accidentaly left the SIMD path on but didn't explore it further.

from openjph.

My understanding is that Kakadu supports quantization for conventional JPEG2000 and HTJ2K when the reversible path is used; all arithmetic is the same, but at the end bitplanes are removed is a rate-distorion optimized way to meet the rate target.

For SIMD, I suspect that I need to write the subroutines to call SIMD instructions for WASM. So the code has to detect if EMSCRIPTEN is used and then select the WASM SIMD subrountines. Ideally, it should also detect if the browser supports SIMD, if not non-SIMD code is called.

from openjph.