TIF: file7 is failing the test suite (should be 16bits)

[GoogleCodeExporter]

According to the openjpeg test suite file7.jp2 does not decode properly:

******Parameters********* 
 base_filename = /home/voxxl/Dashboards/MyTests/data/baseline/conformance/jp2_7.tif
 test_filename = /home/voxxl/Dashboards/MyTests/openjpeg-continuous-linux_gcc47-trunk-debug/tests/conformance/Temporary/file7.jp2.tif
 nb of Components = 3
 Non regression test = 0
 separator Base = _
 separator Test = _
 MSE values = [ 1.000000  1.000000  1.000000 ]
 PEAK values = [ 4.000000  4.000000  4.000000 ]
 Non-regression test = 0
 NbFilename to generate from base filename = 3
 NbFilename to generate from test filename = 3
************************* 
Step 1 -> Header comparison
ERROR: prec mismatch [comp 0] (8><16)

Original issue reported on code.google.com by mathieu.malaterre on 12 Mar 2014 at 2:21

[GoogleCodeExporter]

the baseline file7 tif file does not seems to be quite right. Indeed:

$ tiffinfo data/baseline/conformance/jp2_7.tif
TIFFReadDirectory: Warning, Unknown field with tag 37724 (0x935c) encountered.
TIFF Directory at offset 0x8 (8)
  Subfile Type: (0 = 0x0)
  Image Width: 480 Image Length: 640
  Resolution: 72, 72 pixels/inch
  Bits/Sample: 8
  Compression Scheme: LZW
  Photometric Interpretation: RGB color
  Samples/Pixel: 3
  Rows/Strip: 5
  Planar Configuration: single image plane
  Photoshop Data: <present>, 5040 bytes
  Tag 37724: 0x41,0x64,0x6f,0x62,0x65,0x20,0x50,0x68,0x6f,0x74,0x6f,0x73,0x68,0x6f,0x70,0x20,0x44,0x6f,0x63,0x75,0x6d,0x65,0x6e,0x74,0x20,0x44,0x61,0x74,0x61,0x20,0x42,0x6c,0x6f,0x63,0x6b,0x0
  Predictor: horizontal differencing 2 (0x2)

While:

$ kdu_expand -i data/input/conformance/file7.jp2 -o file7.tif

Consumed 1 tile-part(s) from a total of 1 tile(s).
Consumed 1,354,629 codestream bytes (excluding any file format) = 35.276797
bits/pel.
Processed using the single-threaded environment (see `-num_threads')
$ tiffinfo file7.tif
TIFF Directory at offset 0x8 (8)
  Image Width: 480 Image Length: 640
  Resolution: 0.01, 0.01 (unitless)
  Bits/Sample: 16
  Sample Format: unsigned integer
  Compression Scheme: None
  Photometric Interpretation: RGB color
  Samples/Pixel: 3
  Rows/Strip: 640
  Planar Configuration: single image plane
  ICC Profile: <present>, 13332 bytes

Original comment by mathieu.malaterre on 12 Mar 2014 at 2:27

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Original comment by mathieu.malaterre on 14 Mar 2014 at 2:04

• Changed state: Started

[GoogleCodeExporter]

That would help to have actual correct conformance file.

Original comment by mathieu.malaterre on 14 Mar 2014 at 4:11

[GoogleCodeExporter]

Original comment by antonin on 24 Mar 2014 at 3:55

• Added labels: Conformance

[GoogleCodeExporter]

Original comment by mathieu.malaterre on 24 Mar 2014 at 5:15

• Changed title: TIF: file7 is failing the test suite (should be 16bits)

[GoogleCodeExporter]

Same explanation as in issue 282.

In this case however, the test has to be adapted to downscale the decoder 
output to 8 bits (no component selection needed).

Original comment by antonin on 3 Apr 2014 at 3:44

[GoogleCodeExporter]

The attached patch adds the option to force bit-depth on components of an 
opj_image_t before it's passed to imagetoxxx.
The tests have been modified to add this option : -p 8S, that is precision, 8 
bits, Scaled

"  -p <comp 0 precision>[C|S][,<comp 1 precision>[C|S][,...]]\n"
"    OPTIONAL\n"
"    Force the precision (bit depth) of components.\n"
"    There shall be at least 1 value. Theres no limit on the number of values 
(comma separated, last values ignored if too much values).\n"
"    If there are less values than components, the last value is used for 
remaining components.\n"
"    If 'C' is specified (default), values are clipped.\n"
"    If 'S' is specified, values are scaled.\n"
"    A 0 value can be specified (meaning original bit depth).\n" 

The test ETS-JP2-file7.jp2-compare2ref is now passing.
NR-JP2-file6.jp2-compare2base is now failing (obviously)
NR-JP2-file7.jp2-compare2base did not pass before, no improvement expected & 
none actually.

opj_decompress decode parameters are now distinct from library parameters (I've 
not modified openjpeg.h for obvious reasons).

Now waiting for patch review/comments/modification/commit in order to solve 
issue 282 (force RGB output + force 8bits) & issue 286 (force RGB output).

Original comment by m.darb...@gmail.com on 31 Oct 2014 at 11:05

Attachments:

• issue283.patch

[GoogleCodeExporter]

This issue was updated by revision r2932.

Original comment by m.darb...@gmail.com on 19 Nov 2014 at 8:02

[GoogleCodeExporter]

This issue was closed by revision r2933.

Original comment by m.darb...@gmail.com on 19 Nov 2014 at 8:05

• Changed state: Fixed