Regression against openjpeg 1.3

[GoogleCodeExporter]

What steps will reproduce the problem?
Poppler uses openjpeg optionally to decode JPEG2000 streams present in PDF 
files, we have found that using openjpeg 1.4 instead of openjpeg1.3 gives 
different results (visually wrong). You can find the pdf at 
https://bugs.freedesktop.org/show_bug.cgi?id=43414 
If needed i can try to extract the jpeg2000 stream and provide what where the 
results before and what they are now

What version of the product are you using? On what operating system?
1.3 and 1.4 in linuxLinux

Original issue reported on code.google.com by tsdg...@gmail.com on 6 Dec 2011 at 10:51

[GoogleCodeExporter]

It would be fine to get the original JPEG2000 images of
page 54 of the vision06b.pdf document.

I have compiled poppler first with trunk, then with branch,
of revision 1185.

------------ trunk -----------------
/usr/local/poppler/bin/pdfimages -f 54 -l 54 vision06b.pdf p54
Error: tile 1 of 2

Error: - tiers-1 took 0.040002 s

Error: - dwt took 0.004001 s

Error: - tile decoded in 0.048003 s

Error: tile 2 of 2

Error: - tiers-1 took 0.000000 s

Error: - dwt took 0.000000 s

Error: - tile decoded in 0.000000 s

Error: tile 1 of 2

Error: - tiers-1 took 0.068004 s

Error: - dwt took 0.004001 s

Error: - tile decoded in 0.072005 s

Error: tile 2 of 2

Error: - tiers-1 took 0.004000 s

Error: - dwt took -0.000000 s

Error: - tile decoded in 0.004000 s

Error: tile 1 of 2

Error: - tiers-1 took 0.052003 s

Error: - dwt took 0.004000 s

Error: - tile decoded in 0.060003 s

Error: tile 2 of 2

Error: - tiers-1 took 0.000000 s

Error: - dwt took 0.004001 s

Error: - tile decoded in 0.004001 s

------------- branch ---------------------
No error message.

Both tests create 'wrong' images p54-001.ppm, p54-002.ppm
and p54-004.ppm.

The images on page 54 are correct using XPDF and ACROREAD.

Finally: I use the epdfview-0.1.8 PDF viewer.

And see on page 53:
the left block has a background color near Turquoise3
(#00c5cd) instead of near tan1(#ffa54f), all images
are colored near Tomato3(#cd4f39) instead of near
RoyalBlue1(#4876ff).

Does POPPLER serve the correct colors whereas EPDFVIEW
uses wrong colors?

winfried

Original comment by szukw...@arcor.de on 7 Dec 2011 at 11:02

[GoogleCodeExporter]

Ok, here comes some more info. First some sample code

#include <stdio.h>
#include <string.h>
#include <openjpeg.h>

int main(int argc, char **argv)
{
  unsigned char bigBuf[21501];

  FILE *f = fopen("jpxstream.data", "r");
  fread(bigBuf, sizeof(unsigned char), 21501, f);
  fclose(f);

  opj_dparameters_t parameters;
  opj_set_default_decoder_parameters(¶meters);
  opj_event_mgr_t event_mgr;
  memset(&event_mgr, 0, sizeof(opj_event_mgr_t));
  opj_dinfo_t *dinfo = opj_create_decompress(CODEC_JP2);
  opj_set_event_mgr((opj_common_ptr)dinfo, &event_mgr, NULL);
  opj_setup_decoder(dinfo, ¶meters);
  opj_cio_t *cio = opj_cio_open((opj_common_ptr)dinfo, bigBuf, 21501);
  opj_image_t *image = opj_decode(dinfo, cio);

  printf("image numcomps: %d\n", image->numcomps);

  opj_cio_close(cio);
  opj_image_destroy(image);
  opj_destroy_decompress(dinfo);
}

If i run this code with openjpeg 1.3 i get that numcomps is 1, if i run it with 
openjpeg i get numcomps is 3. This is causing the rest of our code go crazy. 
Can you confirm if that is a regression or there was a bug and the new result 
is the correct one?

Original comment by tsdg...@gmail.com on 8 Dec 2011 at 4:24

Attachments:

• jpxstream.data

[GoogleCodeExporter]

The image 'jpxstream.data' is a J2P file.

In 'jp2_read_ihdr()' the line:

  jp2->numcomps = cio_read(cio, 2);   /* NC */

gives a value of 1 for version3 and version4.

And now the difference in 'jp2_read_jp2h()':

version3 ignores the box types

  JP2_PCLR, JP2_CMAP, JP2_CDEF

whereas version4 reads these boxes. The result in
version4:

'jp2_apply_pclr()' finds

  nr_channels = color->jp2_pclr->nr_channels;

to be 3.

And the resulting image image looks good. Because
version4 uses color values from a color map; whereas
version3 uses the color index values.

I suppose POPPLER wants the color index values, not the
color values.

My question regarding EPDFVIEW seems to be redundant: I 
suppose that EPDFVIEW has a olor problem. I asked you
to be sure that not libopenjpeg creates the wrongs colors 
of the images of the document.

winfried

Original comment by szukw...@arcor.de on 9 Dec 2011 at 10:46

[GoogleCodeExporter]

Well, we use OPENJPEG to decode data that happens to be in a JP2 strea , this 
data may be an image or may be something different, if you preprocess the data 
and convert it to an image we can't use it at all since the data we need is no 
longer there :-/

Original comment by tsdg...@gmail.com on 9 Dec 2011 at 5:45

[GoogleCodeExporter]

I have added a test for this: r1301. I am working on it right now.

Original comment by mathieu.malaterre on 11 Jan 2012 at 9:05

• Changed state: Accepted

[GoogleCodeExporter]

openjpeg 1.4 and 1.5 are producing correct results. openjpeg 1.3 is not.

Original comment by mathieu.malaterre on 11 Jan 2012 at 11:02

[GoogleCodeExporter]

Hi Albert,

I think there were a misunderstanding : there are actually two different bugs.

1/ The one you first spotted and for which you submitted a patch. Many thanks 
for this, I'm currently testing it and investigating another way to do it 
(basically, keep the new flag you suggested (without forgetting to initialize 
it in the default decoder parameters) but use it only in opj_jp2_decode to 
condition the execution of apply_cdef and apply_pclr (lines 752-779 in current 
revision of jp2.c). It will be fixed before release 1.5. If you have easy 
access to the jp2 image that was causing the problem, it's always helpful. Or 
I'll ask you to check it on your side.

2/ The decoding of jpxstream.data : as indicated by Winfried, 1.3 and 1.4 give 
different results (respectively 1 and 3 components). In this case, 1.3 is 
right, the info in the jp2 boxes is misleading 1.4 (and was not taken into 
account in 1.3, which explains the regression. Kakadu gives also only one 
component. This bug will require another patch ... If someone want to submit 
it, it's more than welcome :-).

Original comment by antonin on 13 Jan 2012 at 2:03

[GoogleCodeExporter]

Point 1 in comment above is fixed.

Pont 2 is moved to a new issue #110.

Original comment by antonin on 23 Jan 2012 at 8:23

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by mathieu.malaterre on 28 Feb 2014 at 8:34

• Added labels: Milestone-Release2.1