WCPS1.5_nodata encode parameter not passed to RasQL from WCPS

[Piero Campalani]

Adding a nodata additional parameter to a WCPS encode expression is not effective: the additional parameter is somehow discarded.

See this ​link for examples.

[Piero Campalani]

Note: this problem arises when RGB bands a explicitly created with a range constructor.

The nodata parameter is not passed (a warning is sent from CrsUtil class) since the extra parameters handler does not read the expected dimensions of the output data.

The problem seems to lie in the WCPS RangeCoverageExpr constructor, which overrides its info member (petascope.wcps.server.core.CoverageInfo instance) for every new range component found.

# foreach component in {red, green, blue}:
info = elem.getCoverageInfo(); # overwrite

Taking the example provided by Marcus:

for c in ( mean_summer_airtemp ) 
return encode( 
  struct{ 
   red:     (char) 
        coverage greyImage 
        over $first x(51:150), 
             $second y(0:99) 
        values (($first * ($first > 75) * ($first < 125)) + (($first > 124) * 250)); 
   green: (char) 0; 
   blue: (char) 0 
  } 
, "png", "nodata=250,0,0")

this means that the last range component to be evaluated (blue) — which is read as a 1D element — represents the all RGB construct.

If the coverage constructor — which is read as 2D instead — is left as last component, things work fine:

for c in ( mean_summer_airtemp ) 
return encode( 
  struct{  
   red: (char) 0; 
   green: (char) 0;
   blue: (char) 
        coverage greyImage 
        over $first x(51:150), 
             $second y(0:99) 
        values (($first * ($first > 75) * ($first < 125)) + (($first > 124) * 250))
  } 
, "png", "nodata=0,0,250")

This creates a blue-shaded pic however.
Considering #282, the labels of the range constructor are not considered and the order is fixed to red then green then blue.

A current workaround for this bug is then to construct a null 2D coverage on the Blue band:

for c in ( mean_summer_airtemp ) 
return encode( 
  struct{  
   R: (char) 
        coverage greyImage 
        over $first x(51:150), 
             $second y(0:99) 
        values (($first * ($first > 75) * ($first < 125)) + (($first > 124) * 250));
   G: (char) 0; 
   B: (char) coverage workaround over $ignore1 x(51:150), $ignore2 y(0:99) values 0
  } 
, "png", "nodata=250,0,0")

[Marcus Sen]

OK, I've managed to adapt this workaround successfully for some of our real queries although obviously it is rather ugly and needs fixing really.

[Piero Campalani]

Clearly, this is amongst the ugliest workarounds I ever saw.
Being this a derived issue, I created the ticket #742 whose fix will cascade here.

[James Passmore]

Regarding the transparency and black/white differences (#739)
I know there is some (currently unilateral) discussion going on, thanks to the (great) post by Marcus.

OLD service request returns image ~ a mix of aerial photo and no data (black):

for v1 in (pga_cir) return
    encode(
        scale(
	    trim(struct {red : (char) v1.red; green : (char) v1.green; blue : (char) v1.blue},
	    {x:"http://www.opengis.net/def/crs/EPSG/0/27700"(209208:211662), 
             y:"http://www.opengis.net/def/crs/EPSG/0/27700"(707380:709649)}),
	    {x:"CRS:1"(0:599), y:"CRS:1"(0:553)},
	    {}
	),
	"png"
    )

NEW service request returns image ~ a mix of aerial photo and no data (white transparent):

for v1 in (pga_cir) return
    encode(
	scale(
	    trim(struct {red : (char) v1.red; green : (char) v1.green; blue : (char) v1.blue},
	    {E:"http://www.opengis.net/def/crs/EPSG/0/27700"(209208:211662), 
             N:"http://www.opengis.net/def/crs/EPSG/0/27700"(707380:709649)}),
	    {E:"CRS:1"(0:599), N:"CRS:1"(0:553)},
	    {}
	    ),
	"png"
    )

This above workaround addresses how to pass a nodata value to be used as the transparency as part of a WCPS request, but not the issue of setting 0,0,0 pixels to be transparent by default in rasdaman 9, which is a change in behaviour from Rasdaman 8.

What if I don't want a transparent image?

[Dimitar Misev]

Replying to jpass:

What if I don't want a transparent image?

Hmm good point. I guess you could set nodata to some nonexisting values (as a workaround).

[Dimitar Misev]

#743 for that issue.

[Piero Campalani]

I believe a better workaround (wrt to comment:3) is to extract the coverage construction outside of the range construcor, as done in browser:systemtest/testcases_services/test_wcps/queries/40-range_structure.test.

[Bang Pham Huu]

This problem was fixed in WCPS1.5, regards to Marcus's experiment ​https://groups.google.com/forum/#!msg/rasdaman-users/7LgnH2yKiZg/HsrUuEp-_xcJ 2 problem queries with using nodata

Query 1:

for c in ( mean_summer_airtemp )
return encode(
  struct{
   red:     (char)
        coverage greyImage
        over $first x(51:150),
             $second y(0:99)
        values (($first * ($first > 75) * ($first < 125)) + (($first > 124) * 250));
   green: (char) 0;
   blue: (char) 0
  }
, "png", "nodata=0,0,0;") 

translate to Rasql with "nodata=0,0,0;" in encoding

SELECT encode(((octet) MARRAY ... 
VALUES  (  ( first *  ( first > 75 )  *  ( first < 125 )  )  +  (  ( first > 124 )  * 250 )  )  * {1c,0c,0c} + (octet) 0 * {0c,1c,0c} + (octet) 0 * {0c,0c,1c}), "png" , 

"nodata=0,0,0;") 

FROM mean_summer_airtemp AS c

Same as Query 2 when encode with "nodata=250,0,0;" in WCPS, the generater Rasql is:

SELECT encode(((octet) MARRAY .... VALUES  
(  ( first *  ( first > 75 )  *  ( first < 125 )  )  +  (  ( first > 124 )  * 250 )  )  * {1c,0c,0c} + (octet) 0 * {0c,1c,0c} + (octet) 0 * {0c,0c,1c}), "png" , 

"nodata=250,0,0;") 

FROM mean_summer_airtemp AS c

In WCPS1.0, it actually does not regard to the "nodata" parameter, then it use the default encoding for transparent, i.e only

select .... encode(..., "PNG") without "nodata"

But it will use WCPS1.5 soon, then this ticket can be closed here.