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
  • 5
Peter Krauss
  • 747
  • 1
  • 9
  • 23
  • The choice of format will have a lot to do with the nature of the data (colour / grayscale / bw, bit-depth, resolution, and importantly whether it's mostly text, photos, charts, blurry, grainy, etc) so it would help a bit if you could elaborate on that. More importantly - was the original scanned TIFF lossy or lossless? If it was lossy, it means that this loss of information was condoned (unlike further changes), and you are highly unlikely to find a lossless format which will match it's file size. – Daniel B Apr 18 '13 at 11:53
  • 4
    This would be on-topic here Peter if you A) made it not a resource request but rather requesting an answer to your question and B) clarified what the question is. The topicality of your Q is actually a great fit here, you just need to clarify a specific answerable question. – Jimmy Hoffa Apr 18 '13 at 14:47
  • Thanks @JimmyHoffa et al! I edited, but perhaps later, other people closed the question... – Peter Krauss Apr 18 '13 at 15:21
  • Thanks @thorstenMüller, check if now (edited) is more explicit. – Peter Krauss Apr 18 '13 at 15:23
  • 6
    @PeterKrauss I know it's not clear by the wording of "close" but close actually means locked until revised, fix it up and it will be re-opened, they would delete it if they didn't think it could be fixed. – Jimmy Hoffa Apr 18 '13 at 15:30
  • Potential answerers to this (great) question: note simply looking at software which alleges to support JPEG2000, or even can open it, is not enough! Take a look at the list of objections in the article Peter linked to, which include "not keeping the ICC profile" and "changing the resolution" (plus some other objections!) – Andres F. Apr 22 '13 at 20:05
  • I added some examples of organizations switching to JPEG 2000 to my answer. Take a look. – Randall Cook Apr 23 '13 at 23:40
  • Related on the Libraries & Information Science SE - [Is JPEG2000 really a good preservation format?](http://libraries.stackexchange.com/questions/1306/is-jpeg2000-really-a-good-preservation-format) –  May 04 '13 at 19:39
  • See good validator http://jpylyzer.openpreservation.org – Peter Krauss Jul 06 '18 at 04:39

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,470
  • 19
  • 19
  • Thanks. Yes, I agree your argumments about "sufficient platform support". Browsers and [GIS applications](http://gis.stackexchange.com/questions/27436/converting-from-geotiff-to-jpeg2000) was the first to support, but [NLM/PMC standards for scanned documents and for original illustrations](http://www.ncbi.nlm.nih.gov/pmc/pub/filespec-images/#img-quality), and others, yet recommends TIFF... I dont know why. – Peter Krauss Apr 22 '13 at 16:45
  • @PeterKrauss I could be wrong on this, but the first thing that comes to mind would be lack of (widespread?) support for multiple pages in one file for JPEG and JPEG-2000? Support for non-lossy compression is another, and the JPEG-family were always photo oriented and don't perform *that* well on scanned documents. Historically, TIFF has been, and still is extremely widespread and dominant in the world of scanning. Asking why is a bit like asking why Windows is dominant on the desktop - it was good enough at the right place and time. – Daniel B Apr 23 '13 at 05:28
  • Unsupported seems way excessive. A survey across several big institutions showed a different picture: http://photo.stackexchange.com/a/69661/45210 – Nemo Oct 06 '15 at 13:28
  • Hi Randall, some news for perspectives in 2021? The link of "adoption by NATO" is not working. – Peter Krauss Aug 19 '20 at 09:42
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
  • 5
  • Yes (!) "mean library", I need to check the "library support coverage" at Linux, Windows and Mac. If the community of developpers and big repositories (like [PMC](https://en.wikipedia.org/wiki/PubMed_Central) and [SciELO](https://en.wikipedia.org/wiki/SciELO)) can adopt jp2.
    Oh, [perfect illustration your samples](http://www.fnordware.com/j2k/jp2samples.html), thanks.
    – Peter Krauss Aug 17 '14 at 18:36
  • 2
    About "*JP2* is out of reach of the people (...) it will never reach the break-even point for public acceptance". Important point to remember here for readers and for comparisons: of course, ***JPG* is "for the crowds"**; today (and perhaps over decades) *JP2*, [JLS](https://en.wikipedia.org/wiki/Lossless_JPEG) and TIFF are **for preservation contexts**, and they are the focus here. – Peter Krauss Aug 18 '14 at 09:53