Golang JPEG2000 implementation / Gauging community interest in supporting it?

[Adam Koszek]

Hello,

We (Segmed.ai) are processing a lot of medical imaging data. It comes to us in the form of PNG/JPG/DICOM files. 90% of it is uncompressed or using a normal JPEG encoding, but around ~7% of it is encoded with lossless JPEG 2000 format.

We use Suyash Kumar's library: https://github.com/suyashkumar/dicom which depends on the Golang "image/jpeg" library. We'd love to get "image/jpeg" to support JPEG 2000 lossless encoding format.

I know it's rather a rare format, yet it's "the standard". I wonder if there are any other users interested in getting JPEG 2000 supported natively in Go? Or maybe someone out there has its implementation written, and would need hand open-sourcing it?

I was thinking that maybe there are companies that would benefit from it, and we could co-sponsor someone to whip a nice implementation for us. We could probably help with organizing this, pitch in some $$$ too, and manage the work. In case you're a domain expert in search of a cool project, feel free to reply to this post.

Thanks,

Wojciech Adam Koszek

[Nick]

Hi Wojciech,

Quoth Adam Koszek:

> I know it's rather a rare format, yet it's "the standard". I wonder if there
> are any other users interested in getting JPEG 2000 supported natively in Go?
> Or maybe someone out there has its implementation written, and would need hand
> open-sourcing it?
>
> I was thinking that maybe there are companies that would benefit from it, and
> we could co-sponsor someone to whip a nice implementation for us. We could
> probably help with organizing this, pitch in some $$$ too, and manage the work.
> In case you're a domain expert in search of a cool project, feel free to reply
> to this post.

Yeah, in my work on OCR of historical books for rescribe.xyz we come
across JPEG 2000 scans every so often, and having native support in
Go for it would potentially be handy. That said, massive lossless
images are not useful for the use case anyway, so at the moment just
converting them to regular JPEGs using ImageMagick before processing
works just fine.

So consider me an interested party, but not to the extent of being
able to offer much in the way of developer time to the endeavour.
Cheerleading and testing, though, that much I can happily offer :)

Nick

[Dan Kortschak]

Part of the issue here is the availability of the spec. The ITU are
unpleasantly closed (at least for free copies) with spec documents
which reduces the likelihood of open source project implementations.

(Not putting myself forward in the case that a spec is provided).

Dan

[Robert Engels]

There are several open source Java encoder/decoder libraries. These can be translated pretty easily to Go.

> On Nov 5, 2021, at 3:19 PM, 'Dan Kortschak' via golang-nuts <golan...@googlegroups.com> wrote:

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/69f9b44981f8fd9134d9e1ceb3e19f4a6486b75d.camel%40kortschak.io.

[Adam Koszek]

We're trying to do the same - when we encounter a JPEG2000 encoded
file, we convert it. Yet we don't want to keep a converted copy
because often people want to see the data in the original form.

So right now we got a commercial DICOM codec with the capability of
reading / compressing JPEG2000 DICOMs, but it's a hack. We're fork a
process and read converted bytes from STDIN.

Go implementation would be much, much nicer.

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/YYUKu/V5p4pHZKiy%40hammerhead.lan.



--
W. Adam Koszek
CTO and Cofounder, Segmed Inc.
wko...@segmed.ai

[Gwyneth Llewelyn]

I know this is an ancient discussion, but... aye, there is definitely still interest in JPEG2000 after all these years, and there is still no native Go library for them.

It's not only DICOM medical imaging that uses JPEG2000. It's also things like Second Life — where all textures are stored as JPEG2000 files. JPEG2000 has this uncommon advantage of being able to store the same image in different sizes, the smallest/lowest resolution first... which make them ideal for virtual worlds where content is not downloaded in advance, but rather via streaming. That way, a full scene can be rendered with an approximation of the finished version very quickly, with all the low-rez variations being downloaded in a pinch (JPEG2000's compression also helps a lot), while the higher-rez versions can be downloaded slowly, as the user manifests their interest in examining something in detail.

Obviously, there are many ways of accomplishing the same results — storing separate files for each dimension/resolution, for instance — but JPEG2000 has the advantage of doing it all inside the same container.

So, sure, it's still a very relevant format with plenty of niche applications; a pity it's being left behind in favour of AVIF and newer-generation solutions. I have no idea how you can replicate the same in other types of containers, though. I can imagine that you could, in theory, do it using Targa TGA extensions, or possibly even in TIFF — both of wish also becoming obsolete very, very fast.

JPEG2000 is something curious in the history of graphic file formats: it addressed quite a lot of issues with existing contemporary formats, introduced new forms of containers for images, and offered much higher compression — even lossless compression — of higher-quality/resolution images than the 'original' JPEG format. It's even supposed to support animated frames, and who knows what else. Its biggest disadvantage, as always, is related to the legal issues in encoding or decoding JPEG2000 images by reverse-engineering the implementation used by the original libraries — since they all rely on tons of patents from different companies in the consortium....

Anyway, just my $.02: I suppose that this will never become a reality — mostly because we have so many alternative formats already...

    — Gwyn

[Jason E. Aten]

Have you seen the headline numbers on patent suit awards? Violating

patents can run you 100s of millions of dollars --  not joking. There

are whole businesses with winning patent cases as their sole aim.

You might naively think that any patents should have expired since its

been more than 17 years since origination, but clever folks keep

extending them with new versions, and the patent office just

leaves it to the courts to settle.

Not worth touching with a ten foot pole.