r.out.png: respect TRANSPARENT and COMPRESSION enviro vars

[hamish]

Hi,

Peter Löwe discovered that r.out.png does not respect GRASS_TRANSPARENT or GRASS_PNG_COMPRESSION, which limits the module's usefulness. (especially the lack of NULL->alpha)

I'm guessing we should have it respect both GRASS_TRANSPARENT and a module flag, if they conflict I guess go with the enviro variable.

Same for compression with a module option=1-9.

a work-around for now is to use the PNG driver with GRASS_WIDTH and HEIGHT taken from the image meta data.

thanks, Hamish

[glynn]

Replying to hamish:

Peter Löwe discovered that r.out.png does not respect GRASS_TRANSPARENT or GRASS_PNG_COMPRESSION, which limits the module's usefulness. (especially the lack of NULL->alpha)

I'm guessing we should have it respect both GRASS_TRANSPARENT and a module flag, if they conflict I guess go with the enviro variable.

Same for compression with a module option=1-9.

You guessed wrong ;)

GRASS_TRANSPARENT and GRASS_PNG_COMPRESSION are for the display drivers, which don't have the option of reading parameters from the command-line, so they have to use environment variables instead.

r.out.png should use command-line options; it shouldn't be looking at environment variables.

While you're at it, there are a dozen or so other parameters which could reasonably be set by command-line options.

[hamish]

patch to add transparency support to r.out.png

[hamish]

patch attached to add transparency, compression, and background color options to r.out.png. Patch is vs 6.5svn.

• I'm not sure how useful bgcolor= is, as I'm not sure how often "set" is likely to return no-color from G_lookup_raster_colors(), or really what triggers that to be set==0. Or should bgcolor= override the color table's "nv" color for NULL cells when there's no alpha channel? Is "set" like the default("*") lesser used rule in the color tables?

• the pointer for G_is_null_value() is specified in a rather raw way. Ideas for improvement are welcome.

Hamish

[glynn]

Replying to hamish:

patch attached to add transparency, compression, and background color options to r.out.png. Patch is vs 6.5svn.

• I'm not sure how useful bgcolor= is, as I'm not sure how often "set" is likely to return no-color from G_lookup_raster_colors(), or really what triggers that to be set==0. Or should bgcolor= override the color table's "nv" color for NULL cells when there's no alpha channel? Is "set" like the default("*") lesser used rule in the color tables?

r.out.png shouldn't write the background colour into the image data; it should just pass it to png_set_background(). If the image has an alpha channel or transparent colour index but the reader wants an opaque image, the PNG library overlays the image on the background colour.

The "set" value is 0 if the default colour was used, 1 if a colour was found for the cell's value (including null; the null value colour is always defined).

If you want to write an RGB image (no alpha), ignore the "set" value and the bgcolor= option, and just write exactly what G_lookup_raster_colors() returns.

If you want to also write an alpha channel, there are two independent options: whether to make null cells transparent and whether to write cells with no defined colour (set == 0) as transparent. In all cases, the RGB channels should still contain exactly what G_lookup_raster_colors() returns.

• the pointer for G_is_null_value() is specified in a rather raw way. Ideas for improvement are welcome.

Arithmetic on a void pointer is undefined (gcc supports it as an extension). Use:

	size_t rsize = G_raster_size(rtype);
	...
	G_incr_void_ptr(voidc, col * rsize);

[hamish]

ok, second cut committed with r41215.

I'm still not sure about the terms for png_set_background():

source:grass/trunk/raster/r.out.png/main.c@41215#L241​

• how to setup png_color_16p;
• if r,g,b given for png_color_16p, set need_expand = 0 ?
• set background_gamma = 1.0?

Hamish

[glynn]

Replying to hamish:

ok, second cut committed with r41215.

I'm still not sure about the terms for png_set_background():

Oops. I should have said png_set_bKGD(). png_set_background() is only used for reading.

[hamish]

png_set_bKGD()

changed to use that in r41241, but I'm still getting a segfault. confused by the layers of structs and ^usage.

Hamish

ps- what does r.in.png do which r.in.gdal doesn't? is PNG a flexible enough format to help with the 6-7 raster format transition | grass-gdal driver plugin | r.external ?

[glynn]

Replying to hamish:

png_set_bKGD()

changed to use that in r41241, but I'm still getting a segfault. confused by the layers of structs and ^usage.

The (pointer) variable isn't being initialised. Use a structure and pass its address:

        png_color_16 background_color; 
        background_color.red = (png_uint_16)def_red; 
        background_color.green = (png_uint_16)def_grn; 
        background_color.blue = (png_uint_16)def_blu; 
        png_set_bKGD(png_ptr, info_ptr, &background_color); 

ps- what does r.in.png do which r.in.gdal doesn't?

Provides more options, e.g. gamma correction, conversion to float. Also, by default it imports the raw values rather than expanding to bytes.

is PNG a flexible enough format to help with the 6-7 raster format transition | grass-gdal driver plugin | r.external ?

No, it's limited to 16-bit integers.

[hamish]

done in devbr6 and trunk. thanks

qiv 2.1~pre12-5 64bit still goes a bit nuts with the transparent background, but I'm 99% sure that's a qiv bug and not the bit-depth etc being set wrong.

Hamish