Bug#664747: (no subject)

Hi Mathieu,

As the original author of jpylyzer I’ll try to answer your questions. First of all, the meaning of “valid”: with this I mean being in accordance with the formation specification (ISO/IEC 15444-1), i.e.:

http://www.jpeg.org/public/15444-1annexi.pdf

Now for your experiences with those conformance files. Am I correct in assuming that the JP2 conformance files which you are referring to are the ones from ISO/IEC 15444-4:

http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-T.803-200211-I!!SOFT-ZST-E&type=items

If yes, the simple (and perhaps somewhat perplexing) explanation is that *none* of these files are actually in compliance with the standard! There are two problems:

1. All JP2 images in the conformance set have a "Colourspace Approximation" value (APPROX in the Colour Specification box) of 1, whereas section I.5.3.3 of the format spec says that it shall be zero ("other values are reserved for other ISO use"). It also says that conforming readers shall ignore the value of this field.

2. Two of the files in the conformance set are actually JPX files (JPX is an extension of the JP2 format, and it is part of ISO/IEC 15444-2. This is actually mentioned in the description of the data set, but confusingly these files are provided with a JP2 extension. Since the Colour Specification boxes in these files have PREC, APPROX and EnumCS values that are not permitted in JP2 they are not valid JP2.

Issue one will lead to the following specific error:

<tests>

<approxIsValid>False</approxIsValid>

Issue two will result in “False” values for brandIsValid, approxIsValid, precIsValid, and enumCSIsValid. These fields all contain values that are only permitted in JPX (and illegal in JP2).

I have actually brought this issue up to the JPEG committee (in which I am participating myself as a liaison to OPF) back in March. This led to quite a lively discussion; unfortunately I wasn’t quite able to follow up on this due to some unforeseen circumstances shortly after I started the discussion, and it sort of slipped off my radar after that. However, what I learned from the responses is that these are all known issues, but there doesn’t seem to be a lot of agreement as to whether these issues should be addressed or not.

Apparently the use of a non-allowed value of APPROX was done on purpose, the idea being that conforming readers shall ignore this field, i.e. any weird values here shouldn’t break the application.

The JPX files were included to demonstrate the concept of JP2-compatible JPX, but it really is a different format and having these files in a JP2 conformance set is –at least in my opinion- really confusing.

I hope this may have taken away some of your concerns. Please let me know if I can provide any more help or information on this.

Johan van der Knijff