CDEF support patch & alpha saving problem

[Marek Mauder]

I added CDEF box reading and writing to OpenJpeg. There is a
new field in opj_image_comp called comp_type (red, green, y, opacity,
etc...).
If jp2 image contains cdef box comp_type is set accordigly during decoding.
If you want to have cdef box in encoded image you must set proper
channel type
for each image component (otherwise cdef is not written).
Another problem was that METH field of COLR box was only set to
enumerated colorspace for images with 1 and 3 components.

If you saved jp2 image with OpenJpeg and included alpha channel most
image editors/viewers
couldn't opened it because of the METH value. With the proper METH they
opened it but
didn't recognize alpha channel because of the missing CDEF. These two
problems are resolved with
this patch.

But there is another problem when saving multichannel images:
When image is encoded (using lossy compression, lossless is ok),
all values of additional components (first three are ok) are somehow set
to 128.
Someone made a post about it some time ago:
http://groups.google.com/group/openjpeg/browse_frm/thread/bb402110a7020cbd/96805691a0f90685
It looks like it is somehow related to compiler or its settings. I get
this behaviour
with GCC on both Windows and Linux. Strange thing is: I use C++ Builder to
compile OpenJpeg to object files and the link them to Delphi application.
Encoding works ok in Delphi app but when I use those same object files
in C++
application the problem is back.

Another thing is it didn't happen with older versions of OpenJpeg. It
somehow
appeared between 1.0 and 1.2.

Anyone has any idea what can cause this?

[Callum Lerwick]

On Sat, 2008-03-01 at 20:23 +0100, Marek Mauder wrote:
> I added CDEF box reading and writing to OpenJpeg. There is a
> new field in opj_image_comp called comp_type (red, green, y, opacity,
> etc...).
> If jp2 image contains cdef box comp_type is set accordigly during decoding.
> If you want to have cdef box in encoded image you must set proper
> channel type
> for each image component (otherwise cdef is not written).
> Another problem was that METH field of COLR box was only set to
> enumerated colorspace for images with 1 and 3 components.
>
> If you saved jp2 image with OpenJpeg and included alpha channel most
> image editors/viewers
> couldn't opened it because of the METH value. With the proper METH they
> opened it but
> didn't recognize alpha channel because of the missing CDEF. These two
> problems are resolved with
> this patch.

Nice, but this should wait until after v1.3.1 is released to get merged.

> But there is another problem when saving multichannel images:
> When image is encoded (using lossy compression, lossless is ok),
> all values of additional components (first three are ok) are somehow set
> to 128.
> Someone made a post about it some time ago:
> http://groups.google.com/group/openjpeg/browse_frm/thread/bb402110a7020cbd/96805691a0f90685
> It looks like it is somehow related to compiler or its settings. I get
> this behaviour
> with GCC on both Windows and Linux. Strange thing is: I use C++ Builder to
> compile OpenJpeg to object files and the link them to Delphi application.
> Encoding works ok in Delphi app but when I use those same object files
> in C++
> application the problem is back.
>
> Another thing is it didn't happen with older versions of OpenJpeg. It
> somehow
> appeared between 1.0 and 1.2.
>
> Anyone has any idea what can cause this?

Have you tried compiling OpenJPEG with different optimization levels?
Does it still happen with -O0? -O1?

[Galfar]

On Mar 1, 8:58 pm, Callum Lerwick <s...@haxxed.com> wrote:
> Have you tried compiling OpenJPEG with different optimization levels?
> Does it still happen with -O0? -O1?

Thanks for the tip, it is working right with -O0 and -O1, problem
appears with levels 2 and 3 only.

[Callum Lerwick]

Hmmm. Try "-O2 -fno-strict-aliasing". If that fixes it, there's an
aliasing bug that needs to be tracked down:

http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html

Recent versions of gcc have strict aliasing enabled at -O2 and above by
default.

[Dzonatas]

I've tried: -O0 -fstrict-aliasing -Wstrict-aliasing=2
and: -O0 -fno-strict-aliasing

I get the same results where the alpha component is set to byte values
of 128.