At the National Library of Scotland we were finding that some colour profiles in tif files were causing errors when we tried to convert them to JP2. So a couple of weeks ago I posted a question to the DPC-Discussion list asking members for their advice on JP2 files and colour profile support.
In the end we had some great help from Johan van der Knijff, from the Koninklijke Bibliotheek (KB) in the Netherlands, who has given me permission to use a distillation of our email exchange for the benefit of others who may run into the same problem (90% Johan – thanks Johan!) Here's a summary of our findings.
The problem:
- When using Kakadu v7.9 to convert .tif files with certain colour profiles to JP2 Kakadu reports an error and creates a 1KB faulty .jp2 file. The error is:
Error in Kakadu File Format Support:
Attempting to write a colour description (colr) box which uses JPX extended
features to the image header of a baseline JP2 file. You might like to upgrade
the application to write files using the `jpx_target' object, rather than `jp2_target'.
Because we want to create the baseline JP2 file and not JPX this is a problem.
- When using Aware JPEG 2000 SDK to create jp2 files from .tif files with certain colour profiles the jp2 files are created, but when examined with jpylyzer two problems are revealed for two different .tif files with two different embedded colour profiles:
<isValidJP2>False</isValidJP2>
<tests>
<jp2HeaderBox>
<colourSpecificationBox>
<iccNoLUTBasedProfile>False</iccNoLUTBasedProfile>
</colourSpecificationBox>
</jp2HeaderBox>
</tests>
<isValidJP2>False</isValidJP2>
<tests>
<jp2HeaderBox>
<colourSpecificationBox>
<iccPermittedProfileClass>False</iccPermittedProfileClass>
</colourSpecificationBox>
</jp2HeaderBox>
</tests>
The cause:
The problem is not with Kakadu v7.9 or Aware JPEG 2000 SDK (although future releases of Aware could flag up non-compliant JP2s, as Kakadu does, without relying on Jpylzyer), but with the use of certain types of colour profile. Simple profiles like Adobe RGB, sRGB, sGray, ProPhotoRGB, Gamma 1.8 etc. work fine, but others do not. One of the two test files which failed had an embedded ICC profile that was created by the Library a number of years ago which is look-up table based. This is not allowed in JP2. The other test file had an ‘Output Device Profile’ as its profile class. JP2 only allows for ‘Input Device Profile` and ‘Display Device Profile` types.
A potential solution:
You can check for these ICC profile properties directly in your TIFF images with ExifTool (http://www.sno.phy.queensu.ca/~phil/exiftool/), using the –X (uppercase!) switch. E.g.:
exiftool –X whatever.tif > whatever.xml
If the output XML contains an element ‘ICC_Profile:AToB0’ this indicates the embedded ICC profiles uses the lookup-table method. To pick up on an incorrect profile class check the value of the ‘ICC-header:ProfileClass’ element.
At the National Library of Scotland we will build in an automated check for these elements in the file headers prior to converting the input images into JP2. It is likely that for some forms of digitisation we will ask specific input device colour profiles which JP2 doesn’t support to be converted to a common working space with a wide gamut that baseline JP2 does support, such as ProPhotoRGB or AdobeRGB(1998).
In the interests of sharing lessons learned, I hope that others will benefit from this experience and, of course, from the excellent advice from Johan at the KB.