OpenJPEG - use cases

[Henshaw, Christy]

Hi IIIFers,

 

For those of you using, or interested in using, JPEG 2000, I am looking for use cases as to what might motivate funders to contribute to, and therefore speed up, development of OpenJPEG. Your feedback will help me understand better whether we/someone should invest in OpenJPEG when Kakadu does such a great job and has a rather inexpensive cost model for non-profits.

 

Here are some questions I thought might be useful to ask (feel free to add to this):

 

1.     Why do you use OpenJPEG, or why might you want to use OpenJPEG?

2.     If you are not using it, why not?

3.     If you are not using it, would you consider using it if technical improvements could be made?

4.     If you believe technical improvements are required, what do you think should be the top priority?

 

Thanks!

Christy

 

Dr Christy Henshaw 
Digitisation Programme Manager 
Wellcome Library
215 Euston Road
London  NW1 2BE
+44 (0)20 7611 7333 
Chenshaw / WellcomeDigital

 

The Wellcome Trust is a global charitable foundation dedicated to improving health by supporting bright minds in science, the humanities and social sciences, and public engagement.

 

 

This message has been scanned for viruses by Websense Hosted Email Security

[Jon Stroop]

Christy,
It's been at least a year since I looked at OJP (right after the 2.1 release, I believe), but with that caveat:

1.     Why do you use OpenJPEG, or why might you want to use OpenJPEG?

I don't presently use OJP. I would want to use it in order have an open-source alternative to Kakadu. Specific to Loris, Loris does support OJP OR Kakadu, but I highly doubt anyone is using it, because....

2.     If you are not using it, why not?

...performance performance performance. In one circumstance: tile (not precinct, but tile) retrieval, I've seen OJP outpace Kakadu, but the rest of the time, there's no comparison, and above a couple thousand pixels, OJP's performance is not acceptable.

3.     If you are not using it, would you consider using it if technical improvements could be made?

Yes, see #1

4.     If you believe technical improvements are required, what do you think should be the top priority?

See #2. Performance, whatever it takes to do so, should be on par with Kakadu.

I think my answers are mostly obvious, but happy to put them in writing!
-Js

--
-- You received this message because you are subscribed to the IIIF-Discuss Google group. To post to this group, send email to iiif-d...@googlegroups.com. To unsubscribe from this group, send email to iiif-discuss...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/iiif-discuss?hl=en
---
You received this message because you are subscribed to the Google Groups "IIIF Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iiif-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tom Crane]

Hi Christy,

Simple view - I want to be able to build IIPImage from source, or use a ready made distribution, and still have a completely open source stack and not have to acquire a Kakadu licence. Cost is part of this, but not really the only reason. It makes deployment, scaling up etc easier, and doesn't get you involved in procurement issues.

There's also a difference between using Kakadu in the delivery of images over the web and using Kakadu elsewhere, e.g., as part of the digitisation workflow, creating JP2s, where you might also be using several other proprietary apps with predictable usage, and not mind the licence fees. In the delivery of images we're really only concerned with serving tiles as fast as possible, all the other things we might use Kakadu for are not so important. So if OpenJPEG were developed to the point that Ruven or Petr felt it was fast enough to be the default JP2 engine in IIPImage, I'd be happy, even if for other usages (e.g., JP2 encoding) people still preferred Kakadu. 

So...

1.     Why do you use OpenJPEG, or why might you want to use OpenJPEG?
Open source stack, as above. We have open source viewers and open source image servers, but we still need this closed source nugget to access our collections.

2.     If you are not using it, why not?
Because IIPImage doesn't use it

3.     If you are not using it, would you consider using it if technical improvements could be made?
Defer to IIPImage experts. See http://help.oldmapsonline.org/jpeg2000 - this is a bit old, maybe Petr can comment: "Update: initial implementation for OpenJPEG2 has been done. Without additional optimisations of OpenJPEG2 the speed on larger images is still about 1000x faster with Kakadu library."

4.     If you believe technical improvements are required, what do you think should be the top priority?

selfishly speaking, delivery - anything IIPImage needs Kakadu for. Decoding but specifically for generation of tiles (as in tiles served from an image service endpoint rather than the tiles inside the JP2, although the two are connected).

Tom

[Tristan Roddis]

On 09/06/2015 13:14, Henshaw, Christy wrote:

Hi IIIFers,

 

For those of you using, or interested in using, JPEG 2000, I am looking for use cases as to what might motivate funders to contribute to, and therefore speed up, development of OpenJPEG. Your feedback will help me understand better whether we/someone should invest in OpenJPEG when Kakadu does such a great job and has a rather inexpensive cost model for non-profits.

Well done for looking into this, Christy. To my mind the current reliance on the proprietary Kakadu libraries means that the whole IIIF Image API remains firmly in the realm of "specification without a universally accessible implementation", and the substitution of an open source alternative such as OpenJPEG should be a top priority to speed up adoption.

 

Here are some questions I thought might be useful to ask (feel free to add to this):

 

1.     Why do you use OpenJPEG, or why might you want to use OpenJPEG?

I'd want to use OJP to replace Kakadu, and therefore be able to deploy and redistribute IIIF-compliant image servers without having to negotiate and pay licensing.

2.     If you are not using it, why not?

Because its performance is unacceptable (n.b. I've never actually tried this myself, just heard this from multiple sources who have).

3.     If you are not using it, would you consider using it if technical improvements could be made?

Hell, yes. (see #1)

4.     If you believe technical improvements are required, what do you think should be the top priority?

Performance (see #2). For our primary use case (showing scaled and zoomable views of high-res JPEG2000 masters on websites) I'd much rather see an incomplete-but-speedy implementation that worked well for core functions such as resizing, cropping and converting to JPEG, rather than wait for more esoteric features such as rotation or conversion to other formats.

-Tristan.

--

cogapp

Tristan Roddis
Head of Web Development
+44 1273 821 600
www.cogapp.com
 
 
News 
Qatar Museums’ website recently won an international award for Best Cultural Experience. Find out more here.
For more Cogapp news, please follow us on Twitter and LinkedIn

[Jeremy Echols]

We use openjpeg for our tiling image server on the Historic Oregon Newspapers project.  The server, RAIS, is something originally built at the library of congress which we kind of took over when they didn't seem to have much time: https://github.com/uoregon-libraries/rais-image-server

Our rationale was that we couldn't afford the "always on" TIFF storage we had been using.  TIFFs are blazing fast, but obviously eat a great amount of disk.  We needed to go JP2, but we also wanted to help contribute something back to other users of the chronam code (the basis for the oregon news project), and hopefully JP2 users in general.  And the easiest way, in theory, is to use tools that don't require proprietary code you may or may not have to pay for depending on the definitions in their licenses.

The RAIS image server was our attempt to provide this contribution.  It's really fast for tiled images, and it's pretty easy to install... but only after you get openjpeg 2.1 sources installed.

While building RAIS we discovered a few major caveats in openjpeg.  First, as Jon Stroop already mentioned, it doesn't handle non-tiled JP2s very well.  This doesn't affect our use case, as the spec for newspaper JP2s already seemed to require tiled images.  So for those files, our server is actually performing really well.  But toss in some large JP2s that aren't processed properly, and the server can actually die due to lack of RAM :(

Another caveat is just installation pain.  This isn't really openjpeg's problem, but, e.g., users of something like CentOS have to jump through some hoops in order to pull the Fedora openjpeg package and recompile it for CentOS.

These aren't the only issues we have with RAIS, but even if we fixed everything on our end, the openjpeg issues make our system a lot less turnkey for non-chronam use cases.  The non-tiled performance issue in particular is just one more big caveat to add to our README that people probably won't notice.

So I'd second the votes to look at performance of non-tiled images.

Note that I haven't benchmarked against Kakadu, so I don't know how it actually compares - I just know what works for us and what doesn't.
 

[Matt McGrattan]

On Tuesday, 9 June 2015 13:14:21 UTC+1, Christy Henshaw wrote:

Hi IIIFers,

 

For those of you using, or interested in using, JPEG 2000, I am looking for use cases as to what might motivate funders to contribute to, and therefore speed up, development of OpenJPEG. Your feedback will help me understand better whether we/someone should invest in OpenJPEG when Kakadu does such a great job and has a rather inexpensive cost model for non-profits.

 

Here are some questions I thought might be useful to ask (feel free to add to this):

 

1.     Why do you use OpenJPEG, or why might you want to use OpenJPEG?

2.     If you are not using it, why not?

3.     If you are not using it, would you consider using it if technical improvements could be made?

4.     If you believe technical improvements are required, what do you think should be the top priority?

Essentially everything Tom Crane has said.

1) We'd love to be able to use a completely open source stack, top to bottom. Both for our own internal purposes, but also because we want to make Docker images available to other people [as part of our Mellon funded Digital Manuscripts Toolkit] and Kakadu licensing is a barrier to ease of use and ease of deployment that we would prefer not to have.

2) Performance. 

3) Yes, if the performance and IIP integration was there. 

4) Performance.

Thanks!

Matt

[Petr Žabička]

Hi Christy,

at the moment, about 20 Czech libraries use jpeg2000 and IIPImage (Zoomify tiles but we plan to switch to IIIF soon). In MZK, we have about 30 million pages available through IIPImage. As MZK funded Kakadu implementation into the IIPImage we feel in part responsible for its future so we looked into OpenJpeg last year.

We would love to have access to free up-to-date binary IIPImage package with jpeg2000 support out of the box.

I had a student last year who implemented OpenJPEG into IIPImage as his thesis (in Czech, unfortunately). https://goo.gl/Ryf4Q2
For a code repository go here: https://github.com/moravianlibrary/iipsrv-openjpeg

Unfortunately, it turned out that openJPEG is rather slow (as expected). I have asked my colleague to set up this version of IIPImage alongside our production IIPImage so we can compare the user experience - but this will take some time as it is not a high priority project for us.

Best,

Petr
--
Petr Žabička
Moravian Library in Brno
www.mzk.cz

[Henshaw, Christy]

To those who have responded to my questions - thank you! Very useful input, and I'd like to quote directly from some of your comments in my briefing document. This will set out the need for OpenJPEG, why Kakadu isn't quite right for us, and how OpenJPEG will be improved. My goal is to get enough funding for 1 full time developer for 10 - 12 months to do this work.

**To those of you who would expect to use a new and improved OpenJPEG: do you think your institutions would be willing to contribute to the cost?**

If individual institutions could contribute as little 2,000 - 3,000 Euros each (not dissimilar to the cost of a license for commercial JP2 encoders), we wouldn't need a huge number of contributors to meet the target. The Wellcome Library would be very happy to contribute to the work, but we cannot fund it by ourselves.

If you think this sounds like a possibility - or if it doesn't! - please let me know so I can consider the best route to raising the funding. Feel free to contact me directly if you prefer at c.he...@wellcome.ac.uk.

Best,
Christy

This message has been scanned for viruses by Websense Hosted Email Security - www.websense.com

[Ruven]

Hi Christy,

I agree with pretty much everything that has been said in the replies so far. I think it's essential that there exists a high performance open source library for JPEG2000. OpenJPEG is good and is improving all the time, but is simply too slow at the moment and it additionally has problems with very large images. Nevertheless, I intend to take another look at OpenJPEG at some point and add full support within IIPImage for it despite it's flaws, so that users who don't want to use Kakadu can still use use JP2 images. And I think your idea of funding some development is a great idea!

Ruven

[Aaron Boxer]

Hello All,

I realize this is an old thread, but for those of you interested in an open source high performance JPEG 2000 codec, check out my Grok project:

https://github.com/GrokImageCompression/grok

This is a fork of OpenJPEG that provides the following additional features:

1) higher performance : single image decode is about 1/3 the speed of the latest Kakadu, and I am hoping to improve this to 1/2 speed this year
2) dramatically lower memory consumption: for single tile images, memory usage is less than 1/2 that of OpenJPEG
3) full support for gigapixel images
4) fast sub-tile decode:  for large single-tile images, it is possible to decode a sub-region of the tile at high speed

The project is licensed under the Affero General Public License, so it is compatible with iipsrv, for example.

https://en.wikipedia.org/wiki/Affero_General_Public_License

Cheers,
Aaron

[David Haskiya]

Hi Christy,

I can't speak for the Wikimedia Commons community (I upload images there sometimes, my own and other GLAMs, but I'm not a very active community member) but I suspect they would not accept using a the proprietary Kakadu. They're very stringent on not using patent-encumbered formats, see https://commons.wikimedia.org/wiki/Commons:File_types 

Though I note looking at that link they don't currently support JPEG2000 either.

Cheers,

David