OFFSITE and non 8bpp raster images

[bugzilla@…]

Adding Frank to the bug since there is no raster only component.

Steve

[bugzilla@…]

I have a raster with values from -100 to 100 and -101 means OFFSITE.
I would like to be able to declare OFFSITE -101 on my layer, but it is needed to
declare "OFFSITE RRR GGG BBB".

I've been trying to use:

CLASS
    EXPRESSION ([pixel] = -101)
    COLOR -1 -1 -1
END

I need to set output to PNG24 because with PNG i get blue pixels instead of
transparent ones!! This is no good solution because resulting images are 3-4
times bigger than 8 bpp ones.

I have also tryed "FILTER ([pixel] = -101) but nothing happens.

It seems there is no easy way to filter offsite pixels in my Int16 rasters.

[sdlime]

This one is totally out of my area of expertise. Reassigning...

Steve

[fwarmerdam]

Francisco,

I don't think OFFSITE works in a useful fashion for non-8bit rasters.  
However, I think if you use classes, it is sufficient to ensure that the
nodata value does not fall into any valid class. 

FILTERs do not apply to raster layers, except (possibly) to raster queries. 

If, with these caveats, you still think something is not working properly, 
you will need to attach a sample input file, map and command to demonstrate
the problem. 

[bugzilla@…]

raster and mapfile to test

[bugzilla@…]

> I think if you use classes, it is sufficient to ensure that the
nodata value does not fall into any valid class. 

You are right Frank. There are workarounds (this ticket is an "enhancement
request"). I can also preprocess my images.
But in some cases i just need to draw the raster image without classes. I just
need to remove background. And i don't want to preprocess because i want to
preserve original rasters, and i dont have enough hard disk space to keep two
copies of each image.

> FILTERs do not apply to raster layers, except (possibly) to raster queries. 

So there is no performance gain using FILTER. Ok.
How about OFFSITE? 

Anyways, i think there must be a bug somewhere in mapserver dealing with
transparencies and/or alpha.
I have attached an small sample showing the problem it doesn't seem to be
related (only) with 16 bpp as it happens with 8bpp image.

I just want to use:

CLASS EXPRESSION ([pixel] = xxx) COLOR -1 -1 -1  END

In order to filter background color and simplify subsequents expressions, and i
get errors (white instead of transparent).

Note: I can't use OFFSITE because nodata is -101 in my rasters.

Could you please fix the "-1 -1 -1" bug?

[warmerdam]

On mapserver-dev I have written the following with regard to use of -1 -1 -1 for transparent. I will note that -255 -255 -255 in the map file works fine as a transparent color for raster classes.

In bug 1806 there is a report that COLOR -1 -1 -1 is not being treated as transparent when classifying raster data. Investigating I find that the code is checking for transparent as -255 -255 -255 using:

#define MS_TRANSPARENT_COLOR(color) (((color).red==-255

(color).green==-255

(color).blue==-255)?MS_TRUE:MS_FALSE)

In fact, -1 -1 -1 is the default value to which colors are initialized and it is considered "invalid" according to:

#define MS_VALID_COLOR(color) (((color).red==-1

(color).green==-1

(color).blue==-1)?MS_FALSE:MS_TRUE)

I have found no material discussing such color values in the reference documentation, though the mapserver tutorial does suggest using -1 -1 -1 as a color for classified data to make it transparent.

The vector code likely does effectively treat this as transparent, but the raster code treats invalid, but not transparent as a special case meaning use the underlying color of the raster data instead of applying a color based on classification. I hesitate to break this capability by treating invalid as transparent.

Also, I find in the mapsymbol.h include file that colorObj now has an alpha field. I'm not clear on how widely this is being used, or whether it is intended to be the "future" of transparency.

Should we document -255 -255 -255 as transparent? Promote use of alpha?

[warmerdam]

I have reviewed some of the other issues, and come to the conclusion that:

1) test-1 does not work because there is only one fixed color class with no expression. The mapdrawgdal.c code deciding if things are classified assumes that such a degenerate case is a class introduced only to put the raster in the legend - a common approach.

2) test-2 : it ought to be testing [pixel] <65535 for the 16bit case instead of 255. When this is done things work well.

3) test-3 similar to test-2,and the scaling has no significant effect one way or the other.

I'm will try to act on feedback on the mailing list with regard to the -1 -1 -1 transparency issue, but for the most part I judge there is no real bug here.