search

iron261 / openjpeg

Automatically exported from code.google.com/p/openjpeg
Other
0 stars 0 forks source link

Transparency problem #416

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
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

Original issue reported on code.google.com by 24horasm...@gmail.com on 21 Oct 2014 at 11:50

GoogleCodeExporter commented 9 years ago 
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)

Original comment by m.darb...@gmail.com on 22 Oct 2014 at 10:42

GoogleCodeExporter commented 9 years ago 
http://www.libpng.org/pub/png/apps/pngcheck.html

Original comment by m.darb...@gmail.com on 22 Oct 2014 at 10:44

GoogleCodeExporter commented 9 years ago 
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!!

Original comment by 24horasm...@gmail.com on 22 Oct 2014 at 12:11

GoogleCodeExporter commented 9 years ago 
So is this issue fixed ?

Original comment by antonin on 22 Oct 2014 at 12:45

GoogleCodeExporter commented 9 years ago 
@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.

Original comment by m.darb...@gmail.com on 22 Oct 2014 at 3:08

Attachments:

GoogleCodeExporter commented 9 years ago 
Attached is what OpenJpeg outputs for now

Original comment by m.darb...@gmail.com on 22 Oct 2014 at 3:34

Attachments:

GoogleCodeExporter commented 9 years ago 
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

Original comment by 24horasm...@gmail.com on 22 Oct 2014 at 5:14

Attachments:

GoogleCodeExporter commented 9 years ago 
Sorry I attached wrong images...

Original comment by 24horasm...@gmail.com on 22 Oct 2014 at 5:20

Attachments:

GoogleCodeExporter commented 9 years ago 
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

Original comment by m.darb...@gmail.com on 22 Oct 2014 at 10:27

Attachments:

GoogleCodeExporter commented 9 years ago 
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>

Original comment by m.darb...@gmail.com on 22 Oct 2014 at 10:30

GoogleCodeExporter commented 9 years ago 
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 ?)

Original comment by m.darb...@gmail.com on 23 Oct 2014 at 9:26

Attachments:

GoogleCodeExporter commented 9 years ago 
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 ?

Original comment by antonin on 30 Oct 2014 at 6:37

GoogleCodeExporter commented 9 years ago 
@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.

Original comment by m.darb...@gmail.com on 30 Oct 2014 at 11:06

Attachments:

GoogleCodeExporter commented 9 years ago 
This issue was closed by revision r2923.

Original comment by antonin on 3 Nov 2014 at 2:12