The Zombie Stack Exchanges That Just Won't Die
I've been wondering of late about JPEG2000. I appreciate there are some good reasons to use it as a preservation format, but I'm becoming increasingly alarmed by lack of tool support. This format has been around for 12 years, and yet there are very few tools that manipulate/render these images and of these, it seems only OpenJPEG is open source and freely available. Sun/Oracle's Java Advanced Imaging API is defunct and along with it Java support for JPEG2000.
If lack of popularity is a problem for long-term digital preservation, why are we still banging the JPEG2000 drum?
Peter Cliff
There are significant concerns about longevity as you note in the question, however there are two big wins for the archival community in using JP2: access/delivery features and compression. The latter in particular has led to JP2 being adopted quite rapidly by libraries for storing master files from mass digitisation projects (i.e. 1 million+ images). Short term storage cost savings can be quite significant when the data is squashed down to around 10% of its original size without huge loss of quality. Whether this turns out to be a a sensible choice over the medium to long-term is less clear.
JPEG2000 expert, Johan van der Knijff identifies 5 specific preservation risks for JP2:
A number of these risks have been reduced or mitigated by the emergence of a thorough validation tool: Jpylyzer, which was developed in direct response to a number of specific JP2 related risks and use cases.
The expansion of the last risk lists 3 open source decoders but provides little in the way of further reassurance on this point.
Sadly, I think you are right to be alarmed. Johan van der Knijff's JPEG 2000 for Long-term Preservation and Ensuring the suitability of JPEG 2000 for preservation provide some useful information. But in the end I think having to do practical work with JP2, particularly using opensource software, is the best measure of JP2's use as an image preservation format.
We are heavily dependent on the closed source, proprietary Aware SDK for using JP2 files as the access copy of newspaper images in the National Digital Newspaper Program's Chronicling America web application. We just haven't found any opensource solutions that let us use the JP2 at scale. This is a big barrier to us making our software available to other NDNP partners. It's so much of a barrier that we have talked about using a high-res JPEG for the access copy, since our informal testing in the project's web-based zoomviewer failed to show any noticeable differences with the JPEG2000.
If we have trouble providing access to JP2 data today, this doesn't bode well for tomorrow. As my colleague David Brunton has quipped:
Preservation is just access, in the future.
I think this whole discussion is about the quality of implementations. The points that were mentioned only compare pure encoding. Nobody actually talked about the whole suite like JPIP for streaming. The things that we did for medicine yielded better results in terms of quality and speed than standard JPEG implementations. Especially our current developments for iOS based on Kakadu showed results that are beyond belief. I know that this sounds like self-marketing but even the biggest companies haven't implemented what is possible with JPEG2000 and I talked to many of them. Kakadu is by far the best API, especially performance-wise.
Noboy will ever implement JPEG2000 with a single line of code like we were used to and that is the only reason why the adoption rate is low. What is worse, we all got used to simply copying images. Especially with mobility coming more and more into play, JPIP beats all current encoding and streaming approaches. The downside is of course the complexity and time you need to invest.
Although it is self-marketing, I am happy to show samples to people who are interested. iOS unfortunately takes until Q1/13 for the public App Store.
As another data point, Luratech was strong on supporting JPEG2000 when the Harvard Library moved to their ICS from Aware (largely on my recommendation). Since then, they've lost interest, and the last couple of times we asked for improvements, they asked if we would help finance them. The last I looked for alternative implementations, there weren't a lot. I found Kakadu's licensing information very confusing.
In addition to the risks mentioned by Paul Wheatley above, I recently found out that Adobe already stopped supporting JPEG 2000 altogether in Photoshop Elements in 2011. More details here:
http://wiki.opf-labs.org/display/TR/JPEG+2000+support+discontinued+in+Photoshop+Elements
This definitely isn't going to help further acceptance by general audiences (outside the niche markets where JPEG 2000 is widely used, e.g. digital cinema). It also says something about Adobe's confidence in the format. This wouldn't necessarily matter, were it not for the fact that they're leading the market in this segment.
JPIP for me is about efficiency. If you buy a shirt and your size is XL, you don't order XXL and cut it back down to XL once it is delivered. But that happens every day when large images are copied to mobile devices when only a fraction of the data could be streamed via JPIP. This drives me crazy on a daily basis in my main area medicine. With the technology change towards mobile instead of Desktop, the time is right for a change from jpg to jpeg2000, at least in scientific areas.