Transparency problem

[gcode-importer]

Originally reported on Google Code with ID 416

What steps will reproduce the problem?
1. Run opj_compress with a png as an input file with transparency

What is the expected output? What do you see instead?
The expected output is the equivalent jp2 file but instead I get an opaque jp2


What version of the product are you using? On what operating system?
openjpeg 2.1.0 on windows 7


Please provide any additional information below.

Already tried Issue 414 solution without success

Reported by 24horasmagicascivac on 2014-10-21 11:50:04

[gcode-importer]

Hi,

Many options possible with PNG & transparency/alpha. Could you please paste the output
of pngcheck -pv here so that the issue can be reproduced (or better, the png image
if there are no problems sharing it)

Reported by mayeut on 2014-10-22 10:42:46

[gcode-importer]

http://www.libpng.org/pub/png/apps/pngcheck.html

Reported by mayeut on 2014-10-22 10:44:00

[gcode-importer]

File: D:\RTT\Investigation\2014\ImageFormats\JPEG2000Creation\AJU_00.png (223366 bytes)
  chunk IHDR at offset 0x0000c, length 13
    1280 x 768 image, 32-bit RGB+alpha, non-interlaced
  chunk IDAT at offset 0x00025, length 223309
    zlib: deflated, 32K window, maximum compression
  chunk IEND at offset 0x3687e, length 0
No errors detected in D:\RTT\Investigation\2014\ImageFormats\JPEG2000Creation\AJU_00.png
(3 chunks, 94.3% compression).

Thanks a lot!!

Reported by 24horasmagicascivac on 2014-10-22 12:11:00

[gcode-importer]

So is this issue fixed ?

Reported by detonin on 2014-10-22 12:45:52

[gcode-importer]

@antonin,

This has nothing to do with Issue 414.
The ouput from pngcheck allows to pick a similar image from png test suite to test
OpenJpeg (http://www.schaik.com/pngsuite/) & see if issue can be reproduced.

pngcheck -pv basn6a08.png
File: basn6a08.png (184 bytes)
  chunk IHDR at offset 0x0000c, length 13
    32 x 32 image, 32-bit RGB+alpha, non-interlaced
  chunk gAMA at offset 0x00025, length 4: 1.0000
  chunk IDAT at offset 0x00035, length 111
    zlib: deflated, 32K window, default compression
  chunk IEND at offset 0x000b0, length 0
No errors detected in basn6a08.png (4 chunks, 95.5% compression).

trunk r2911 :

opj_compress -i basn6a08.png -o 0.jp2 -n 5
[INFO] tile number 1 / 1
[INFO] Generated outfile 0.jp2

opj_dump -i 0.jp2
...
Image info {
         x0=0, y0=0
         x1=32, y1=32
         numcomps=4
                 component 0 {
                 dx=1, dy=1
                 prec=8
                 sgnd=0
        }
                 component 1 {
                 dx=1, dy=1
                 prec=8
                 sgnd=0
        }
                 component 2 {
                 dx=1, dy=1
                 prec=8
                 sgnd=0
        }
                 component 3 {
                 dx=1, dy=1
                 prec=8
                 sgnd=0
        }
}
....

The 4 components are in the jp2 file but without a 'cdef' box, a viewer may not consider
the 4th channel as an alpha channel.

Reported by mayeut on 2014-10-22 15:08:10

---

- _Attachment: basn6a08.png
_ - _Attachment: [PngSuite.LICENSE](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-416/comment-5/PngSuite.LICENSE)_

[gcode-importer]

Attached is what OpenJpeg outputs for now

Reported by mayeut on 2014-10-22 15:34:55

---

- _Attachment: [0.jp2](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-416/comment-6/0.jp2)_

[gcode-importer]

The difference I see between basn6a08.png and 0.jp2 is that the alpha channel is deleted.
What I would need is the same content in basn6a08.png but in JPEG2000 format. The key
would be to create a 'cdef' box?

Attached original (arrow.png) and the output of OpenJpeg (arrow.jp2)

Thanks a lot for your help

Reported by 24horasmagicascivac on 2014-10-22 17:14:23

[gcode-importer]

Sorry I attached wrong images...

Reported by 24horasmagicascivac on 2014-10-22 17:20:59

---

- _Attachment: arrow.png
_ - _Attachment: [arrow.jp2](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-416/comment-8/arrow.jp2)_

[gcode-importer]

The alpha channel is not deleted. It's not mapped properly.
Seems that OpenJpeg can't create 'cdef' out of the box.
By inserting a 'cdef' box by hand, we can see that the alpha channel is properly seen
by any viewer.

N = 4
Cn0 = 0, Typ0 = 0, Asoc0 = 1
Cn1 = 1, Typ1 = 0, Asoc1 = 2
Cn2 = 2, Typ2 = 0, Asoc2 = 3
Cn3 = 3, Typ3 = 1, Asoc3 = 0

Not sure if this is to be considered a bug, a limitation & if/when it'll be fix

Reported by mayeut on 2014-10-22 22:27:53

---

- _Attachment: [0-cdef.jp2](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-416/comment-9/0-cdef.jp2)_

[gcode-importer]

Just to enhance the difference (cdef box) between the 2 files :

kdu_jp2info -i /Users/Matt/Downloads/0.jp2 
<JP2_family_file>
  <ftyp name="file-type box" header="8" body="12" pos="12">
    <brand> "jp2_" 0x6A703220 </brand>
    <minor_version> 0 </minor_version>
    <compatible_brand> "jp2_" 0x6A703220 </compatible_brand>
  </ftyp>
  <jp2h name="JP2-header box" header="8" body="37" pos="32">
    <ihdr name="image-header box" header="8" body="14" pos="40"></ihdr>
    <colr name="colour box" header="8" body="7" pos="62"></colr>
  </jp2h>
  <jp2c name="contiguous-codestream box" header="8" body="530" pos="77">
    <codestream>
      <width> 32 </width>
      <height> 32 </height>
      <components> 4 </components>
      <tiles> 1 </tiles>
    </codestream>
  </jp2c>
</JP2_family_file>

kdu_jp2info -i /Users/Matt/Downloads/0-cdef.jp2 
<JP2_family_file>
  <ftyp name="file-type box" header="8" body="12" pos="12">
    <brand> "jp2_" 0x6A703220 </brand>
    <minor_version> 0 </minor_version>
    <compatible_brand> "jp2_" 0x6A703220 </compatible_brand>
  </ftyp>
  <jp2h name="JP2-header box" header="8" body="71" pos="32">
    <ihdr name="image-header box" header="8" body="14" pos="40"></ihdr>
    <colr name="colour box" header="8" body="7" pos="62"></colr>
    <cdef name="channel-definition box" header="8" body="26" pos="77"></cdef>
  </jp2h>
  <jp2c name="contiguous-codestream box" header="8" body="530" pos="111">
    <codestream>
      <width> 32 </width>
      <height> 32 </height>
      <components> 4 </components>
      <tiles> 1 </tiles>
    </codestream>
  </jp2c>
</JP2_family_file>

Reported by mayeut on 2014-10-22 22:30:21

[gcode-importer]

Here's a patch for r2918 that fix that issue.
I attached the files now created.

@24horasmagicascivac,
If you can compile trunk r2918 with this patch, you'll get what you want.

@antonin,

The patch was verified against the test suite with no regressions.
However, the cdef automatic addition might require additional review to catch side
effects that could be introduced for other integrators (I did my best but I'm only
human)

Issue 264 (convert.c hell) comes to mind here. Only PNG fixed... (also, why would grayscale
PNG be converted to RGB jp2 ?)

Reported by mayeut on 2014-10-23 21:26:28

• Status changed: Verified

---

- _Attachment: [0.jp2](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-416/comment-11/0.jp2)_ - _Attachment: [arrow.jp2](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-416/comment-11/arrow.jp2)_ - _Attachment: [issue416.patch](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-416/comment-11/issue416.patch)_

[gcode-importer]

Many thanks Matthieu (for all the patches you're providing actually).

Concerning this one, 15444-1 says that cdef box is optional. To be sure to correctly
understand what you did, it automatically inserts a cdef box only if it detects an
alpha channel, right ? 

Reported by detonin on 2014-10-30 18:37:49

[gcode-importer]

@antonin,

Maybe ISO 15444-1 is not as clear as it should be here.
IMHO, when reading the paragraph for Channel Definition Box, I read that 
- This box shall not exist if the image only contains color channels in the right order
- This box shall exist if the image contains any auxiliary channels or if color channels
are not ordered properly in the code stream

Anyway, the patch only inserts a cdef box given the following conditions :
- valid enumCS (RGB, YUV or GRAY)
- exactly one alpha component provided (component.alpha != 0)
- This alpha channel appears at a later position than color channels (as we assume
that color channels are ordered properly in this box)

The first components are assumed to be color channels, the only alpha component is
the alpha channel, other component are marked as unknown.

Reported by mayeut on 2014-10-30 23:06:52

---

- _Attachment: [issue416-r2922.patch](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-416/comment-13/issue416-r2922.patch)_

[gcode-importer]

This issue was closed by revision r2923.

Reported by detonin on 2014-11-03 14:12:11

• Status changed: Fixed