Distorted / Shifted colors on PPC Mac OSX

[springmeyer]

was able to get an image rendered with trunk on PPC arch. Certain colors get distinctly shifted. See attached examples for the same XML on both intel and ppc.

[springmeyer]

Image rendered in i386 arch

[springmeyer]

messed up render on PPC/leopard and Mapnik trunk

[springmeyer]

Looks a bit like an alpha issue.

Mapfile here: http://mapnik-utils.googlecode.com/svn/trunk/nik2img/tests/mapfile_wgs84.xml

[jburgess777]

swap byte order during set/get rgba value

[jburgess777]

Could you try out the mapnik-rgba-endian.patch on PPC?

I think the issue is that most the color handling code assume little endian (i.e. Red component is agbr_ & 0xff). The code is mostly self-consistent in this assumption, but the routines which access the raw RGBA values directly need byte swapping on big endian arches.

[jburgess777]

second attempt, OSX does not have the htole32 macros

[springmeyer]

works for background, not labels

[springmeyer]

mapnik-rgba-endian3.patch works for the background color but does not catch the labels. hmmm

[jburgess777]

The label rendering goes via: render_halo() & render_bitmap() which calls blendPixel() which then manipulates the raw data in the Image32 pixmap.

I think someone needs to take a look at how the pixmap data is handled inside Mapnik. In an ideal world we would perform the byte swapping in a single place but is is not clear to me where that should be.

[artem]

Starting from r1218 mapnik::color's internal storage has changed. We store individual color components rather then one int32_t. Overall this makes it a bit easier to work with diffrent byte orders etc. Moving to 0.6.2 as it needs some more work.

[springmeyer]

r1218 is nice, but needs the global header so that MAPNIK_BIG_ENDIAN is defined properly. added in r1352

[springmeyer]

... appears that 'blendPixel2()', 'set_rectangle_alpha', 'set_rectangle_alpha2', and 'merge_rectangle' all need support for BIG_ENDIAN as well as png256 and jpeg output.

[springmeyer]

r1353 adds support to 'blendpixel2'

[springmeyer]

r1354 fixes problem writing to png256

[springmeyer]

r1355 fixes writing to jpeg

[springmeyer]

r1357 fixes an issue that looks to be restricted to big endian systems, whereby when no alpha channel is used rgb(0,0,0) is not placed and effectively becomes fully transparent.

[springmeyer]

bilinear8 scaling also looks like it needs endian awareness, but I'll leave that for another day.

If anyone has ideas about handling these byte order issues more centrally, please advise.

[springmeyer]

If anyone has comments on improving this, reopen, but given current work detailed above big endian colors and rendering are working nicely for most usecases.