Closed GoogleCodeExporter closed 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
http://www.libpng.org/pub/png/apps/pngcheck.html
Original comment by m.darb...@gmail.com
on 22 Oct 2014 at 10:44
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
So is this issue fixed ?
Original comment by antonin
on 22 Oct 2014 at 12:45
@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:
Attached is what OpenJpeg outputs for now
Original comment by m.darb...@gmail.com
on 22 Oct 2014 at 3:34
Attachments:
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:
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:
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
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:
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
@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:
This issue was closed by revision r2923.
Original comment by antonin
on 3 Nov 2014 at 2:12
Original issue reported on code.google.com by
24horasm...@gmail.com
on 21 Oct 2014 at 11:50