lossy 16bit compression changes black to white

[GoogleCodeExporter]

What steps will reproduce the problem?
1. image_to_j2k.exe -i 2.raw -o 2.j2k -r 20 -F 2048,2816,1,16,u -s 1,1 -I -b 
16,16
2.
3.

What is the expected output? What do you see instead?

the left area of the image should be black instead of white => expected pixel 
value 0


What version of the product are you using? On what operating system?

openjpeg-1.5.0-win32-x86, win 7 64bit

Please provide any additional information below.

lossless compression is ok, by the way the Issue 62 is still not fixed, 
therefore I have to use -b 16,16 otherwise image_to_j2k.exe will crash

Original issue reported on code.google.com by mm7...@googlemail.com on 29 Mar 2012 at 8:52

• Blocked on: 16 bits lossy compression #10, [1.5] 16bit compression failure #62

Attachments:

• 2.zip

[GoogleCodeExporter]

A few comments:

*I can reproduce the issue with lossy
*I can reproduce the issue with crash (remove -b 16,16 from command line)

Even if the left side of image is black, the right side of the image is simply 
junk. I do not believe openjpeg 1.5.0 does cope with your image.

Original comment by mathieu.malaterre on 21 May 2012 at 10:27

• Changed state: Accepted

[GoogleCodeExporter]

Here is the correct (lossless) result using:

$ kdu_compress -i 2.rawl -o 2.j2k Sprecision=16 Ssigned=no Sdims="{2816,2048}" 
Creversible=yes

Please note that Y and X are inverted in openjpeg vs kakadu notation

Original comment by mathieu.malaterre on 21 May 2012 at 10:32

Attachments:

• 2_kakadu.j2k

[GoogleCodeExporter]

Ok I see what is going on. Your .raw is little endian. while .raw for openjpeg 
(and kakadu signify big endian)

$ dd conv=swab if=2.raw of=2.rawl

looks much better !

Original comment by mathieu.malaterre on 21 May 2012 at 3:43

[GoogleCodeExporter]

This issue was updated by revision r1691.

Original comment by mathieu.malaterre on 29 May 2012 at 9:30

[GoogleCodeExporter]

This is generating correct data:

$ image_to_j2k -i 2.rawl -o 2.j2k  -F 2048,2816,1,16,u

this is not (data look trashed):

$ image_to_j2k -i 2.rawl -o 2.j2k  -F 2048,2816,1,16,u -I

I am using the new rawl module to use your data untouched

Original comment by mathieu.malaterre on 29 May 2012 at 9:44

[GoogleCodeExporter]

Original comment by mathieu.malaterre on 29 May 2012 at 1:14

[GoogleCodeExporter]

Original comment by mathieu.malaterre on 29 May 2012 at 1:15

• Now blocked on: [1.5] 16bit compression failure #62

[GoogleCodeExporter]

Original comment by mathieu.malaterre on 29 May 2012 at 3:41

• Added labels: Milestone-Release2.0

[GoogleCodeExporter]

Original comment by mathieu.malaterre on 25 Feb 2014 at 4:05

• Added labels: Milestone-Release2.1
• Removed labels: Milestone-Release2.0
• Now blocked on: 16 bits lossy compression #10, [1.5] 16bit compression failure #62

[GoogleCodeExporter]

This issue was updated by revision r2482.

Original comment by mathieu.malaterre on 26 Feb 2014 at 3:20

[GoogleCodeExporter]

This issue was updated by revision r2483.

Original comment by mathieu.malaterre on 26 Feb 2014 at 3:21

[GoogleCodeExporter]

If I used the attached patch, valgrind seems happy now, and no stack trashing 
occurs. However the generated image is very very weird.

Original comment by mathieu.malaterre on 4 Mar 2014 at 5:09

Attachments:

• issue141.patch

[GoogleCodeExporter]

Original comment by mathieu.malaterre on 14 Mar 2014 at 2:05

• Changed state: Started

[GoogleCodeExporter]

Original comment by mathieu.malaterre on 25 Mar 2014 at 10:38

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

This issue was updated by revision r2966.

Original comment by m.darb...@gmail.com on 20 Dec 2014 at 1:02

[GoogleCodeExporter]

This issue was closed by revision r2967.

Original comment by m.darb...@gmail.com on 20 Dec 2014 at 1:03

• Changed state: Fixed