Skip to content

TestSuiteDocumentation

Jump to bottom
Antonin Descampe edited this page Apr 28, 2015 · 1 revision

TEST SUITE openjpeg

Conformance testing

These tests are hardcoded in tests/conformance/CMakeLists.txt and they return to the logic described in Standard (Part 4). The data is stored in OPJ_DATA_ROOT/input/conformance.

Decoding

It is necessary:

  • to decode each file provided by the committee. => ETS-CxPx-${filenameInput}-decode
  • comparing the extracted file with the file reference provided by some tolerances also provided (Tables C1, C4, C6 and C7 version ISO / IEC 15444-4:2004). => ETS-CxPx-${filenameInput}-compare2ref

For the daily monitoring of lib, we added tests that compare the output with an uncompressed file baseline and to ensure non-regression of these lib files conformance => CxPx-NR-${filenameInput}-compare2base.

Note 1: it is possible for a file the first two tests pass but the latter fails because of an amendment to Part lossy decompression. It would then be possible after analysis of why to update the baseline to take the test. Indeed primortdial test is to stay within the tolerances provided by the standard.

In addition to ensure non regression of the primary file, we set up tests to write to a text file the information in the main header. => $ {NR} filenameInput-dump. This text file is then compared with baseline => $ {NR} filenameInput compare_dump2base.

Note 2: reading tests of the main header JPEG2000 files have a different output from the version of the trunk and that of the 1.5 so the baselines corresponding start and opj opj_v2 respectively.

Conclusion: there is no need to add input files to this part of the tests, only the baselines tests compare2base comparedump2base and in some cases may be updated.

TODO: in the case files. JP2 of conformance, there is no comparison tests with the reference or at the baseline (see issue 100)

Encoding

No test suite specified by the standard.

Regression tests

The main tests of regression are based on the file /tests/nonregression/test_suite.ctest.in them together in a simple form for the user. In fact the user can add a command line on a file to compress or decompress the file and automatically via the associated regression testing will be generated.

Decoding

From a command line type j2k_to_image-i-o file.j2k file.j2k.pgx, the following tests are generated:

  • it executes the command line => $ NR-DEC-INPUT_FILENAME_NAME {} - $ {} IT_TEST_DEC-decode
  • TODO should compare the output of the previous test with a baseline to ensure non-regression (see issue 100)

Note: If the latter is achieved, it would be necessary to add a baseline every time we add a command line in the file j2k_to_image test_suite.ctest.in

Encoding

From a command line type j2k_to_image-i-o file.j2k file.j2k.pgx, the following tests are generated:

  1. it executes the command line => $NR-ENC-${INPUT_FILENAME_NAME}-{encode}-IT_TEST_ENC
  2. is written to a file the file information generated by the previous test in order to verify that the correct parameters have been used for encoding => $NR-ENC-{INPUT_FILENAME_NAME}-{$}-dump IT_TEST_ENC
  3. Comparing the file generated by the previous test with a baseline => NR-ENC-${INPUT_FILENAME_NAME}-{$}-IT_TEST_ENC compare_dump2base
  4. If kdu_expand is available, it decodes the encoded file by openjpeg with kakadu => NR-ENC-${INPUT_FILENAME_NAME}-IT_TEST_ENC-decode-ref
  5. If kdu_expand is available, we compare the output of the previous test with a baseline => NR-ENC-INPUT_FILENAME_NAME $ {} - {$}-IT_TEST_ENC compare_dec-ref-out2base

It is necessary to add two baselines every time we add a command line with image_to_j2k in tests/nonregression/test_suite.ctest.in (see point 3 and 5).

j2k_dump

Each file in the directory added JPEG2000 OPJ_DATA_ROOT/input/nonregression is listed in the tests/nonregression/CMakeList.txt and automatically generates two tests:

  • we write JPEG2000 file information for entry into a text file => NR-${INPUT_FILENAME_NAME}-dump
  • Comparing the file generated by the previous test with a baseline => NR-${INPUT_FILENAME_NAME}-compare_dump2base It is therefore necessary to add a baseline every time we add a JPEG2000 file in the directory OPJ_DATA_ROOT/input/nonregression (see point 2).

svn

When conformance and/or nonregression files are added to the svn/data trunk, one must make sure to use proper mime-type to avoid svn doing EOL conversion. For PPM/PGM files, one can check:

$ file -i nonregression/*.ppm
nonregression/opj_a1_mono.ppm: image/x-portable-greymap; charset=binary
nonregression/opj_a2_colr.ppm: image/x-portable-pixmap; charset=binary
nonregression/opj_a3_mono.ppm: image/x-portable-greymap; charset=binary
nonregression/opj_a5_mono.ppm: image/x-portable-greymap; charset=binary
nonregression/opj_b1_mono.ppm: image/x-portable-greymap; charset=binary
nonregression/opj_b3_mono.ppm: image/x-portable-greymap; charset=binary
nonregression/opj_c1_mono.ppm: image/x-portable-greymap; charset=binary
nonregression/opj_c2_mono.ppm: image/x-portable-greymap; charset=binary
nonregression/opj_d1_colr.ppm: image/x-portable-pixmap; charset=binary
nonregression/opj_d2_colr.ppm: image/x-portable-pixmap; charset=binary
nonregression/opj_f1_mono.ppm: image/x-portable-greymap; charset=binary
nonregression/opj_f2_mono.ppm: image/x-portable-greymap; charset=binary

in which case it is simply:

$ svn propset svn:mime-type image/x-portable-greymap nonregression/*mono.ppm
property 'svn:mime-type' set on 'nonregression/opj_a1_mono.ppm'
property 'svn:mime-type' set on 'nonregression/opj_a3_mono.ppm'
property 'svn:mime-type' set on 'nonregression/opj_a5_mono.ppm'
property 'svn:mime-type' set on 'nonregression/opj_b1_mono.ppm'
property 'svn:mime-type' set on 'nonregression/opj_b3_mono.ppm'
property 'svn:mime-type' set on 'nonregression/opj_c1_mono.ppm'
property 'svn:mime-type' set on 'nonregression/opj_c2_mono.ppm'
property 'svn:mime-type' set on 'nonregression/opj_f1_mono.ppm'
property 'svn:mime-type' set on 'nonregression/opj_f2_mono.ppm'

followed by:

$ svn propset svn:mime-type image/x-portable-pixmap nonregression/*colr.ppm
property 'svn:mime-type' set on 'nonregression/opj_a2_colr.ppm'
property 'svn:mime-type' set on 'nonregression/opj_d1_colr.ppm'
property 'svn:mime-type' set on 'nonregression/opj_d2_colr.ppm'

encapsulated stream extraction

openjpeg test suite requires that the input is either a jp2 or a j2k. Sometimes the bug appears within an encapsulated stream, eg. DICOM or PDF.

DICOM extraction

To extract a JP2 file from a DICOM file, you can use GDCM tools. Steps on a debian system:

$ sudo apt-get install libgdcm-tools

Easy case, single image:

$ gdcmraw corrupt.dcm output.j2k
$ file output.j2k
output.j2k: JPEG 2000 codestream

While forbiden, it happens that a JP2 file is contained instead of a JPEG 2000 codestream, you need to pay attention to file extension for a clean test suite in OpenJPEG:

$ gdcmraw bogusjp2.dcm output.jp2
$ file output.jp2
output.jp2: JPEG 2000 Part 1 (JP2)

In some cases multiples JPEG 2000 codestream are contained in the DICOM file:

$ gdcminfo multi.dcm
MediaStorage is 1.2.840.10008.5.1.4.1.1.12.1 [X-Ray Angiographic Image Storage]
TransferSyntax is 1.2.840.10008.1.2.4.90 [JPEG 2000 Image Compression (Lossless Only)]
NumberOfDimensions: 3
Dimensions: (512,512,4)
...

In which case you need to use the following syntax:

$ gdcmraw --split-frags -i multi.dcm -o output --pattern %02d.j2k
$ file output*.j2k
output00.j2k: JPEG 2000 codestream
output01.j2k: JPEG 2000 codestream
output02.j2k: JPEG 2000 codestream
output03.j2k: JPEG 2000 codestream

pdf extraction

To extract a JP2 file from a PDF file, you can use mupdf tools. Steps on a debian system:

$ sudo apt-get install mupdf-tools

Display the list of JPEG 2000 streams (JP2 file):

$ mutool show  corrupt.pdf grep | grep JPXDecode
corrupt.pdf:5: <</BitsPerComponent 8/ColorSpace/DeviceRGB/Filter[/JPXDecode]/Height 48/Length 282624/Subtype/Image/Type/XObject/Width 48>>

The above case is easy since there is only a single object (object #5) to extract:

$ mutool show -be -o obj5.jp2 corrupt.pdf 5
$ file obj5.jp2
obj5.jp2: JPEG 2000 Part 1 (JP2)

pdf extraction (difficult)

Sometimes the PDF comes from a fuzz engine. And the PDF itself is corrupted. So it is harder to extract the JP2 stream. In those case, you can use the pdf2jp2 command line tool (UNIX only) from openjpeg. You'll find it at:

https://code.google.com/p/openjpeg/source/browse/trunk/tests/pdf2jp2.c

Of course you need to uncomment the line:

https://code.google.com/p/openjpeg/source/browse/trunk/tests/CMakeLists.txt#103

To have it compiled on your machine. Enjoy (feel free to report also bug with this tool on the mailing list)

Clone this wiki locally