Trying to continue this thread,
http://groups.google.com/group/openjpeg/browse_thread/thread/4683bba9660c2779
but google will not let me. so heres a new one
I spent some time looking at this today, and got the following results
(v1.3 this is on)
Windows 32 bit does not have this problem
Linux 32 bit compiled with -O3 does have this problem
Linux 32 bit compiled with -O0 does not have this problem
Linux 64 bit has this problem
So its very arch/compiler specific, looking at the resulting files
between linux 32 bit -O3 and Linux 64 bit (by converting a 4 channel
tga to j2k and back) the results for the j2k stage were identical for
both fail situations. SO i brute forced it looking for differences in
the code at run time and hit a bunch of issues that all stemmed back
to mct.c, and in particular the arrays of size [3] being accessed by
mct_getnorm_real() and mct_getnorm()
This in turn is accessed by t1_getwmsedec(), now t1_getwmsedec() knows
which component we are on, so for a 4 channel image its calling the
mct_getnorm() with ordinals of 0,1,2,3 so its an array overrun. Now i
guess that windows and linux 32bit no opt are working because that
array overrun hits a non-zero memory location, on linux 64 bit and
optimised that location appears to be 0 which then cascades back
through the code multipling things by 0 and screwing the encode up.
So i quickly did this to test
--- openjpeg-1.3+dfsg.orig/libopenjpeg/mct.c
+++ openjpeg-1.3+dfsg/libopenjpeg/mct.c
@@ -34,12 +34,12 @@
/* <summary> */
/* This table contains the norms of the basis function of the
reversible MCT. */
/* </summary> */
-static const double mct_norms[3] = { 1.732, .8292, .8292 };
+static const double mct_norms[5] = { 1.732, .8292, .8292, .8292 , .
8292 };
/* <summary> */
/* This table contains the norms of the basis function of the
irreversible MCT. */
/* </summary> */
-static const double mct_norms_real[3] = { 1.732, 1.805, 1.573 };
+static const double mct_norms_real[5] = { 1.732, 1.805, 1.573 ,
1.573, 1.573};
/* <summary> */
/* Foward reversible MCT. */
and it works, i can encode and decode 4 channel images with out ending
up with a 50% alpha applied to the whole image.
Now the questions are, what is the *correct* implementation of a
solution?
Should the norms be defined for channels >0,1,2 should mct_getnorm_real
() just limit to a maximum ordinal of 2, or should t1_getwmsedec() or
further up the call stack know better and not actually expose
t1_getwmsedec() to this situation in the first place?
Regards
robin