<Leptonica> pixWrite causing color corruption on PowerPC

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use convertformat.c to convert a 24 bit PNG image to a ppm image using the 
format as IFF_PNM
2. Test it on a PowerPC machine

What is the expected output? What do you see instead?
The color of the image shouldn't be corrupted on PowerPC but the color of the 
image gets corrupted.

What version of the product are you using? On what operating system?
leptonica-1.68
GNU/Linux PowerPC

Please provide any additional information below.
The conversion from png to pnm is working as expected in GNU/Linux Intel but 
not on PowerPC  

Original issue reported on code.google.com by saa...@gmail.com on 6 Aug 2012 at 5:42

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

It is going to the d=24(RGB) branch.

Original comment by saa...@gmail.com on 8 Aug 2012 at 10:24

[GoogleCodeExporter]

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

[GoogleCodeExporter]

Yes. It still gets corrupted.

Original comment by saa...@gmail.com on 29 Nov 2012 at 5:42

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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