21

The general recommendation to record original scanned images used to be "use TIFF". But programmers need evolution of format for "evolution of software", and I need to evolve my system to change from TIFF to JP2.

I have a big image storage (terabytes) for legal and scientific scanned materials, they need original recording. I use some caching rules, but the system need to show (via web download) or to manipulate (ImageMagick and others) original data.

I've read an article about migrating image storages from TIFF-lossless to JPEG-2000-lossless and the conclusion is to stay with TIFF. However the article is from 2009 and at the time they found support for the JPEG-2000 format by available software was very poor. The conversions to JPEG-2000 were lossy in the software they tested, and the available software for consuming images did not support the format well.

Is now the time to change from TIFF to JP2, or not? Is the software support still as flawed as it was in 2009?

Nemo
  • 109
Peter Krauss
  • 785
  • 1
  • 9
  • 23

2 Answers2

8

Based on Wikipedia's list of applications, support these days looks pretty good. It is also gaining traction in archive-oriented organizations worldwide:

  • Here's a page discussing its adoption by NATO, among others.

  • This paper mentions that the Harvard University Library is moving to JPEG-2000 as well.

  • This paper goes into detail on the British Museum and Harvard efforts, and adds the Wellcome Digital Library.

On my MacBook Pro running 10.7.5, here are some browser results (source 1, source 2):

  • Safari: no trouble

  • Chrome: sometimes needed to load QuickTime

  • Firefox: no trouble

I didn't test IE, but from those three, and the Wikipedia list, I think JPEG-2000 support is now widespread.

Regarding the issue of whether you should switch, since JPEG-2000 appears to have sufficient platform support now, I would switch only if there are strong technical reasons for doing so:

  • smaller image sizes

  • faster performance

  • more secure

  • TIFF is starting to be unsupported.

If you choose to switch, please post back with your experiences in doing so!

Randall Cook
  • 2,480
4

I think the answer depends on if you are questioning real life usage or library support coverage. Since you ask on programmers.stackexchange, maybe you mean library, but everyone seems to be assuming you asks about applications. I'll follow the crowd.

Speaking of applications, based on Wikipedia's list of applications, support these days looks pretty bad. The user software compatible with it are numbered, and usually are professional tools, and it is only gaining traction in some worldwide archive-oriented organizations that you can finish listing within one page. In short, jp2 is out of reach of the people. At this rate, it will never reach the break-even point for public acceptance, despite technical superiority.

Speaking of browsers, Wikipedia listed that only Safari has native support. All others, Firefox, Chrome, IE... don't, except some do with QuickTime, which can't be guaranteed on Android/Windows and is not there on Linux.

On my OpenSUSE 13.1, here are some browser results with samples (note that open the sample page does not count towards OK, you have to open the .jp2 images inside it):

  • Chromium 33: Can't do it, offer users to download.
  • Firefox 27: Can't do it, offer users to download.

(Since Linux itself support jp2, users can open the images after download)

**Edit after reading Peter Krauss' comment ** In the preservation context perhaps you can choose the format, because usually you supply users with tools; the users' desktop and browser environment are of secondary importance.

Evolving your software doesn't mean accepting latest technology standard. Latest technology standard is the hope of future technology of the standard committee, and people vote by feet after their decision. Examples: A lot migrated to XHTML then HTML5 while most from HTML4 directly to HTML5, and a lot migrated to FireWire (1394) then eSATA and USB3 while most from USB2 directly to USB3.

Nemo
  • 109