Open GoogleCodeExporter opened 9 years ago
This is likely an endian problem on the powerPC, where it should be compiled
with L_BIG_ENDIAN but instead the endian flag on the compile line is
L_LITTLE_ENDIAN.
If you built with autoconf, look at the Makefile(s) that you generated in the
./configure phase. In particular, make sure that ENDIANNESS is correct in the
src and prog Makefiles. If not, edit those files.
Original comment by dan.bloo...@gmail.com
on 7 Aug 2012 at 5:02
I checked the Makefiles in src and prog. The endianness is set to L_BIG_ENDIAN.
When pixWriteStreamAsciiPnm is used instead of pixWriteStreamPnm, no color
corruption is observed. But, writing ASCII pnm files is costly in terms of time
and memory. Please check and let us know.
Original comment by saa...@gmail.com
on 7 Aug 2012 at 11:10
Is it going through the d=24 or d=32 branch of pixWriteStreamPnm()?
Original comment by dan.bloo...@gmail.com
on 8 Aug 2012 at 4:38
It is going to the d=24(RGB) branch.
Original comment by saa...@gmail.com
on 8 Aug 2012 at 10:24
I don't see how it's possible to go through the d=24 branch. convertformat
reads the RGB image into a 32 bpp pix.
Do you still get corruption if you write to png format?
Original comment by dan.bloo...@gmail.com
on 14 Sep 2012 at 9:40
Yes. It still gets corrupted.
Original comment by saa...@gmail.com
on 29 Nov 2012 at 5:42
The problem is with PixWriteStreamPnm().
When it writes the pnm file contents, the contents of the RED channel are zero.
I noticed this discrepancy from the hexdump. Not sure why it is happening so.
Could you please check on the same?
Original comment by saa...@gmail.com
on 17 Jun 2013 at 7:12
Another Update :
I am not using convertformat.c
I am directly calling pixWriteMemStream().
Original comment by saa...@gmail.com
on 17 Jun 2013 at 7:14
I don't believe we ever resolved your problem. If not, I need you to do some
more test. First, please download 1.70 from www.leptonica.org. Then,
(1) Verify with print statments whether it's going through the d=24 loop at l.
432 or the d=32 loop at l.440 of pnmio.c.
(2) If it is going through d=32, change pel[0] ==> pel[3] and pel[1] ==>
pel[2], and pel[2] ==> pel[1] in l.444 - l.446. Does that fix the problem?
Original comment by dan.bloo...@gmail.com
on 6 Feb 2014 at 4:07
Ignore (2) -- that's wrong.
Instead, add this line after pword = ... on l.443
converOnBigEnd32(*pword);
Original comment by dan.bloo...@gmail.com
on 6 Feb 2014 at 4:47
Original issue reported on code.google.com by
saa...@gmail.com
on 6 Aug 2012 at 5:42Attachments: