Status request: is this still under active development? about jpeg2000

[iszak]

It's unlikely, but some progress will be made in the next few months. I will keep this ticket open for others to see. Contributions are always welcome.

[John-Nagle]

OK. Thanks.
I'm using some of the JPEG 2000 decoders that are just wrappers for existing C code for now. An all-Rust version would be nice but is not essential.

[John-Nagle]

I see there's been progress! Great! Is it far enough along that I should try some decoding?

[John-Nagle]

Tried it.

./jp2000 decode ~/Shared/bricks.jp2
Error: "unexpected box type [0, 47, 0, 0] at offset 8"

[John-Nagle]

jpeg2000examples.zip
Simple brick wall texture.

[iszak]

Hello, apologies for the delay I have been away. Yes, there's been some progress on decoding the part 1 codestream markers, but not the decoding itself, but it should not error.

It appears that the example file is a codestream as opposed to a codestream wrapped in a JP2 container - this is not currently supported. What suggests this is the first 4 bytes appear to be codestream markers 0xFF4F (SOC - Start of codestream) and 0xFF51 (SIZ - Image and tile size) as opposed to the JP2 box length.

I will look into supporting decoding codestream files without the JP2 container for testing purposes.

[John-Nagle]

Interesting. GIMP 2.10 will open that file. It's a brick texture.
That's a texture file in the format used by Second Life and Open Simulator. I'm writing a viewer for Second Life / Open Simulator in Rust. Right now, I'm decoding JPEGs by running the OpenJPEG command line program in a subprocess. This is inefficient. An all-Rust solution would be better. So that's the use case.
Glad to see work continues.

[John-Nagle]

Renamed the file to bricks.jpc and tried the latest decoder. The "decode" subcommand runs with no errors, and

./jp2000 jpxml ~/Shared/bricks.jpc

produces a reasonable XML description of the file contents.
So, the header part is working fine. Any hope on the image decoding?

[iszak]

I am currently at packet decoding, full image decoding may take some time even for simple use cases and even once done, there are likely bugs and performance improvements that can then be done. It may be quicker to use or write bindings to an existing decoder. I will try and improve transparency of current progress in the read me.

[John-Nagle]

OK. I'm using OpenJPEG now, but it's flaky, unsafe, and the subject of security advisories. Grok wont't compile cross-platform. Yours is the closest thing to something that could potentially be trusted in the address space of other code.