search

xinxinlx / openjpeg

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

OpenJPEG does not deal with some input BMP #203

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. image_to_j2k -i 000001.bmp -o 000001.j2k -r 80 -b 32,32
2. j2k_to_image -i 000001.j2k  -o 000001_coded.bmp

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

A compressed version of the grayscale image. 

See 000001_coded.bmp for the image that is obtained
See 000001.j2k for that j2k image that is obtained.
I believe there is something very wrong.

What version of the product are you using? On what operating system?
This mistake happened with the 1.5.1 version and with the 2.0.0 version
in Windows. Version Debug. Compiled with Visual Studio C++.

Please provide any additional information below.

This same mistake happened with other grayscale images with similar 
width and height.

Thanks,
Guilherme Pinto

Original issue reported on code.google.com by guilherm...@gmail.com on 14 Dec 2012 at 7:28

Attachments:

GoogleCodeExporter commented 9 years ago 
Please use -b 64,64 instead of -b 32,32 to reproduce the problem. 

Thanks,
Guilherme Pinto

Original comment by guilherm...@gmail.com on 14 Dec 2012 at 7:41

GoogleCodeExporter commented 9 years ago 
An additional comment: this error appeared even for the option -r 1.

Thanks,
Guilherme Pinto

Original comment by guilherm...@gmail.com on 14 Dec 2012 at 10:55

GoogleCodeExporter commented 9 years ago 
The logic of bmptoimage() is wrong.

The image 000001.bmp has a bitcount(8) and an encoding(RGB).

'bmptoimage()' in 'image_to_j2k.c' finds:

convert.c:bit_count(8) compression(RGB)

But below line 728 in 'convert.c':

if (Info_h.biBitCount == 8 && Info_h.biCompression == 0)/*RGB */

it states:

convert.c:numcomps(1) color_space(CLRSPC_GRAY) has_color(0)

winfried

Original comment by szukw...@arcor.de on 16 Dec 2012 at 1:31

GoogleCodeExporter commented 9 years ago 
Any idea how can I successfully use the function image_to_j2k  to encode the 
Figure 000001.bmp ?

I created this file using the matlab function imwrite.

Thanks,
Guilherme Pinto

Original comment by guilherm...@gmail.com on 21 Dec 2012 at 6:11

GoogleCodeExporter commented 9 years ago 
I  believe the image 000002.bmp attached also has a bitcount(8) and an 
encoding(RGB),
but I am able to compress it. Why ?

Thanks in advance,
Guilherme

Original comment by guilherm...@gmail.com on 21 Dec 2012 at 6:16

Attachments:

GoogleCodeExporter commented 9 years ago 
>I  believe the image 000002.bmp attached also has a bitcount(8) and an 
encoding(RGB),
>but I am able to compress it. Why ?

Yes, 000002.bmp has bitcount(8) and encoding(RGB). And I do not know why you
have been able to compress it.

Do you have applied the patch I have sent to the list?

winfried

Original comment by szukw...@arcor.de on 23 Dec 2012 at 8:10

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
I have been able to compress it without the patch. You can try.

I am almost sure it is related to the size of the image: height and width.
This problem just happens with images of this size:  height and width.

If you want, I can send you images with similar to 000001.bmp or 000002.bmp
that have the same behavior.

BY the way, where is the patch ?

Thanks,
Guilherme

Original comment by guilherm...@gmail.com on 23 Dec 2012 at 8:47

GoogleCodeExporter commented 9 years ago 
Just try to compress it 000002.bmp with the without the patch. You will see 
that it is possible.

Original comment by guilherm...@gmail.com on 23 Dec 2012 at 8:48

GoogleCodeExporter commented 9 years ago 
Here is the patch.

winfried

Original comment by szukw...@arcor.de on 23 Dec 2012 at 7:32

Attachments:

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Hello,

I included the patch. 

Now the problem is that I am using, as input, an image with just one 
component(grayscale), but the output is one image with three components.

Moreover, it seems that the patch treats the input image as a rgb image.  

This causes a problem in the computation of the compression ratio. With the 
change,
the image is bigger with respect to number of bits than it should be.

Thanks,
Guilherme

Original comment by guilherm...@gmail.com on 24 Dec 2012 at 3:21

GoogleCodeExporter commented 9 years ago 
The input images (000001.bmp and the nice 000002.bmp) do have both
bitcount(8) and encoding(RGB); not encoding(GRAY).

Both images do NOT have one component but three components.

The old version of 'bmptoimage()' treated both images as GRAY with
one component. And therefore the output image was distorted.

>This causes a problem in the computation of the compression ratio. 
>With the change, the image is bigger with respect to number of bits 
>than it should be.

The output image is as big as it shall be: the input images have a
color map, the output image does not have one.

179078 Dec 24 08:06 000001.bmp
  6590 Dec 24 08:28 000001.bmp.j2k
530054 Dec 24 08:28 000001.bmp.j2k.bmp

The size problem depends on the missing color map handling in 
'imagetobmp()'.

winfried

Original comment by szukw...@arcor.de on 24 Dec 2012 at 6:47

GoogleCodeExporter commented 9 years ago 
Hi winfried,

What is the status of this issue?
If I well understand your patch solve the first problem about image with 
encoding RGB but not the last problem.
Mickaël

Original comment by savmick...@gmail.com on 4 Feb 2013 at 1:03

GoogleCodeExporter commented 9 years ago 
Mickaël,

I do not know what the first and the last problem is. I only know that
with the patch I proposed both images (000001.bmp,000002.bmp) can be
read and compressed.

winfried

Original comment by szukw...@arcor.de on 18 Mar 2013 at 9:44

GoogleCodeExporter commented 9 years ago 
Patch does not apply anymore.

$ patch --verbose -F 50 -p1 --dry-run < 
/tmp/openjpeg-branch15-r2258-convert.c.dif 
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjpeg-branch15-r2258/applications/codec/convert.c.orig  2012-12-18 
02:42:08.856231203 +0100
|+++ openjpeg-branch15-r2258/applications/codec/convert.c   2012-12-19 
10:23:13.449597834 +0100
--------------------------
Patching file applications/codec/convert.c using Plan A...
Hunk #1 FAILED at 500.
1 out of 1 hunk FAILED -- saving rejects to file 
applications/codec/convert.c.rej
done

Original comment by mathieu.malaterre on 24 Feb 2014 at 1:41

GoogleCodeExporter commented 9 years ago

Original comment by mathieu.malaterre on 24 Feb 2014 at 1:42

GoogleCodeExporter commented 9 years ago 
If I convert the input file from BMP to PGM then everything is solved. Our BMP 
parser must be broken. We should really move to a third party lib to handle BMP 
file instead of having our own parser. Eg, http://code.google.com/p/libbmp/

Original comment by mathieu.malaterre on 27 Feb 2014 at 4:12

GoogleCodeExporter commented 9 years ago 
All image viewer I have show a distorted image for '000001_coded.bmp':

flimage : distorted
gqview  : distorted
gm animate : distorted
animate : distorted with the report
  animate: length and filesize do not match `000001_coded.bmp' 
           @ warning/bmp.c/ReadBMPImage/820
iv : does show no image but informs:
     width: 353
     height: 1 078
     bytes per pixel: 4
     framesize: 1 522 136
     filesize: 179 078

This image is broken.

winfried

winfried

Original comment by szukw...@arcor.de on 6 Mar 2014 at 3:47

GoogleCodeExporter commented 9 years ago 
But with the patched 'convert.c', the resulting image '000001_coded.bmp' 
is OK for v1.5 and v2.x .

winfried

Original comment by szukw...@arcor.de on 6 Mar 2014 at 4:08

GoogleCodeExporter commented 9 years ago 
the patch does not apply on v2.x, how did you applied it ?

Original comment by mathieu.malaterre on 14 Mar 2014 at 3:13

GoogleCodeExporter commented 9 years ago 
How do you want this patch:

1. diff -u convert.c.orig convert.c > convert.c.dif

2. complete 'convert.c'-file

3. bmptoimage() as a block: call it middle.

   delete everything below line 531 of convert.c: call it head
   delete everything above line 1027 of convert.c: call it tail
   cat middle >> head
   cat tail >> head
   mv head convert.c

winfried

Original comment by szukw...@arcor.de on 18 Mar 2014 at 7:00

GoogleCodeExporter commented 9 years ago 
The files '000001.bmp' and '000002.bmp' you find above.
Other BMP files are in the archive 'bmp-images.tgz'.

winfried

Original comment by szukw...@arcor.de on 19 Mar 2014 at 9:06

Attachments:

GoogleCodeExporter commented 9 years ago 
Issue 353 has been merged into this issue.

Original comment by m.darb...@gmail.com on 20 Dec 2014 at 6:28

GoogleCodeExporter commented 9 years ago 
From Issue 353,
code expects a bmp header size of 40 bytes, and bails
if header is larger.

Header can in fact be as large as 124 bytes (ICC profiles)

See:

http://en.wikipedia.org/wiki/BMP_file_format

Original comment by m.darb...@gmail.com on 20 Dec 2014 at 6:28

GoogleCodeExporter commented 9 years ago 
This issue was updated by revision r2971.

Original comment by m.darb...@gmail.com on 20 Dec 2014 at 6:45

GoogleCodeExporter commented 9 years ago 
This issue was updated by revision r2972.

Original comment by m.darb...@gmail.com on 20 Dec 2014 at 6:46

GoogleCodeExporter commented 9 years ago 
This issue was updated by revision r2973.

Original comment by m.darb...@gmail.com on 20 Dec 2014 at 6:58

GoogleCodeExporter commented 9 years ago 
This issue was updated by revision r2974.

Original comment by m.darb...@gmail.com on 20 Dec 2014 at 6:58

GoogleCodeExporter commented 9 years ago 
This issue was updated by revision r2975.

Original comment by m.darb...@gmail.com on 22 Dec 2014 at 1:14

GoogleCodeExporter commented 9 years ago 
This issue was updated by revision r2976.

Original comment by m.darb...@gmail.com on 22 Dec 2014 at 1:14

GoogleCodeExporter commented 9 years ago 
Merged in parts of Winfried patch in convertbmp.c
Added test data.

I added all Gimp could output (except ICC for now, but header size 124 is 
supported with loss of ICC data).

Data is not rescaled to 8bits in some cases & this seems to bother compression :
issue203-32x32-bgr16.bmp output is weird, colors are off.
issue203-32x32-bgra16.bmp won't get encoded.

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

GoogleCodeExporter commented 9 years ago 
This issue was updated by revision r2977.

Original comment by m.darb...@gmail.com on 22 Dec 2014 at 2:40

GoogleCodeExporter commented 9 years ago 
This issue was updated by revision r2978.

Original comment by m.darb...@gmail.com on 22 Dec 2014 at 2:40

GoogleCodeExporter commented 9 years ago 
This issue was updated by revision r2980.

Original comment by m.darb...@gmail.com on 22 Dec 2014 at 3:14

GoogleCodeExporter commented 9 years ago 
I added Winfried test data as well (for images taking a new code path)
bgra16 (b5g5r5a1) is now OK
images in bgr565 (uploaded as bgr16) are not coded properly & I will create an 
issue for this. But there are no more issues with BMP reading as far as I can 
test (a simple test shows that those images are properly read).

I will close this issue. If there are other images that can't be read, please 
open a new issue.

Original comment by m.darb...@gmail.com on 22 Dec 2014 at 6:17