The KB has been decoding jp2 images as a service for well over 12 years now, and has been doing it quite well, for quite a lot of customers.
For those of you who are unfamiliar with on-the-fly decoding of BIG images, this sample links to the interactive viewer in Delpher
It has, however, been worrying our IT department for about the same amount of time nonetheless, because image processing takes a heavy toll on the servers we hosts.
In short, what changed is this: in the year 2019 we finally took away a lot of this worry by adopting the open source library OpenJPEG 2.3.1 As A Service.
Well, at the time I was working as a budding young developer on the new flagship website for our digitization projects (books, periodicals, newspapers), now known as Delpher. The better the website got and the more good publicity our digitization projects got, the more CPU's were stressed by the imaging service we were hosting.
One colleague famously said that a new app(1) would only be a success if it would bring the imaging service to a grinding halt.
And it wasn't cheap either. For every new CPU core we used, we spent a lot of money on licensing fees to the vendor of jp2 decoding software, as well as maintenance fees.
So, due to the nagging worry this caused I first set out trying a free, open source solution, to tackle the problem. This would make scaling out free as far as software was concerned and would give our IT department reassurance that any time a new marketing campaign came around we would be able to add servers to the load-balancing pool.
There were actually some quite some good reasons why it took 6 years to evolve this idea to productive software. One was that our IT-department was primarily Microsoft savvy. Not a complete dealbreaker, but compiling OpenJPEG to a dll and wrapping that As A Service was not something I felt entirely comfortable with. Another was the stability of the service we had been using; you do not just exchange a proven piece of software for something more experimental.
The biggest concern we had was: would OpenJPEG perform fast enough for accessing images on the web? This is why the KB donated a small sum to contribute to a new OpenJPEG development cycle back in 2017.
And by the time they delivered, most of the KB's application park was being ported to Redhat Enterprise Linux, which I felt a lot more comfortable with.
Of course one last question remaining, a valid one I might add: why not use one of these off-the-shelf, IIIF compliant image servers?
Well, because the KB was so early to the party that we hosted an image API for which no standard was available to comply with. If standards were there at all, they were certainly not as ripe and well advertised back then. And the websites we host still speak this internal API.
This type of release had to be seamless with our current infrastructure. Besides the API this was also necessary for the server side bit with respect to file resolving and networking.
That is why I wrote a light-weight, fast, backward compatible wrapper, also supporting the IIIF image API v2.1 at level one, which we hope to expose in the near future. A public version is also available here.
A succesful deployment to production would of course never have been possible without some very important people:
I would also like to stress that this project only succeeded thanks to a style of management in which all these professionals are given enough free mandate to:
René van der Ark - software developer at R&D - KB - National Library of the Netherlands
A more detailed report of our test-results from back in June can be found here.
(1) A temporary gimmick-app called Hier was het Nieuws showing historical newspaper articles about the street you're currently standing on.