[GRASS-dev] cause for bad colors in output from png driver

[Michael Barton]

Thanks. This was a really baffling one.

Michael


On 5/9/07 2:33 PM, "Glynn Clements" <glynn at gclements.plus.com> wrote:

> 
> Michael Barton wrote:
> 
>> I finally isolated the cause of the color issue I¹m having with the PNG
>> driver.
>> 
>> It is the GRASS_TRUECOLOR setting.
>> 
>> If this is set to false, then the PNG looks fine, except that it uses a
>> limited color pallet. If it is set to true, the PNG has black where it
>> should be white and other issues.
>> 
>> 
>> GRASS_PNG_AUTO_WRITE=TRUE
>> export GRASS_PNG_AUTO_WRITE
>> GRASS_RENDER_IMMEDIATE=TRUE
>> export GRASS_RENDER_IMMEDIATE
>> GRASS_TRUECOLOR=TRUE
>> export GRASS_TRUECOLOR
>> GRASS_PNGFILE=map.png
>> export GRASS_PNGFILE
>> 
>> GRASS 6.3.cvs (spearfish60_test):~ > d.barscale tcolor=green
>> PNG: GRASS_TRUECOLOR status: TRUE
>> PNG: collecting to file: /Users/cmbarton/map.png,
>> GRASS_WIDTH=640, GRASS_HEIGHT=480
>> WARNING: Color: can't set color -256
>> 
>> This gives a black background to the barscale
>> 
>> GRASS 6.3.cvs (spearfish60_test):~ > d.legend elevation.10m
>> PNG: GRASS_TRUECOLOR status: TRUE
>> PNG: collecting to file: /Users/cmbarton/map.png,
>> GRASS_WIDTH=640, GRASS_HEIGHT=480
>> WARNING: Color: can't set color -256
>> WARNING: Color: can't set color -16843264
>> WARNING: Color: can't set color -33686272
>> WARNING: Color: can't set color -50529280
>> WARNING: Color: can't set color -50529280
>> ...
>> A lot more of these errors. This is what is locking up the wxPython overlay
>> routine
> 
> Duh; this is related to the changes to support mmap()d files.
> 
> The framebuffer is always stored as B,G,R,A (the format used by 32-bpp
> BMP files). This corresponds to 0xAARRGGBB on a little-endian system
> and 0xBBGGRRAA on a big-endian system (e.g. Mac).
> 
> Externally (DRV_color, DRV_lookup_color), the alpha value is always
> zero (0 = opaque, 255 = transparent), resulting in 0x00RRGGBB on x86
> and 0xBBGGRR00 on Mac. But the valid range of colors is always 0 to
> 0x00FFFFFF inclusive.
> 
> Hence the error on Mac, and why I couldn't reproduce it on x86.
> 
> I'll change it to always use 0x00RRGGBB externally.

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton