So the physical value can be recovered knowing the range as in the code below.
The code for for gray scale is the same, except
that the there only one band. What I would like to know is if should stick to
this or whether I can retool the image creation tools
so that all the information is stored in the image, and if so where can I go to
find out how to do it.
Google so far has failed to answer my questions, but perhaps I am not asking
the right one to begin with.
Thanx
Gaby
BTW I’ve figured I really don’t have to do the the averaging with the
surrounding pixels, since the gc.evaluate(…) method already does a linear
interpolation.
private double getPixelValueInGridSpaceRGB(GridCoverage2D gc, GridCoordinates2D
gcs, double[] range) {
// Get weighted mean of the four surrounding pixels
try {
GridCoordinates2D[] corners = new GridCoordinates2D[4];
corners[0] = new GridCoordinates2D(gcs.x, gcs.y);
corners[1] = new GridCoordinates2D(corners[0].x, corners[0].y + 1);
corners[2] = new GridCoordinates2D(corners[0].x + 1, corners[0].y);
corners[3] = new GridCoordinates2D(corners[0].x + 1, corners[0].y + 1);
double value = 0;
double count = 0;
int[] pixelValue = new int[4];
for (int i = 0; i < 4; i++) {
double distance = gcs.distance(corners[i]);
if (distance == 0) {
// it's exactly on the corner
value = getPixelValue(gc.evaluate(corners[i], pixelValue));
count = 1;
break;
}
distance = 1 / distance;
value += getPixelValue(gc.evaluate(corners[i], pixelValue)) * distance;
count += distance;
}
value = value / count;
// Convert to range space
double mult = value / (256 * 256 * 256);
return range[0] + mult * (range[1] - range[0]);
} catch (Exception e) {
// Outside grid
return Double.NaN;
}
}
/**
* Returns the represented value at the given pixel.
*
* @param pt
* the pixel (guaranteed to be an int,int point)
* @param target
* a non-null four member array for use in the operation. Provided to
* avoid re-instantiation of such an array for repeated pixel
* operations
* @return
*/
protected double getPixelValue(int[] target) {
int result = target[0];
result = result << 8;
result += target[1];
result = result << 8;
result += target[2];
return result;
}
From: Andrea Aime
<andrea.a...@geo-solutions.it<mailto:andrea.a...@geo-solutions.it>>
Date: Friday, 1 August 2014 8:03 pm
To: andrea antonello
<andrea.antone...@gmail.com<mailto:andrea.antone...@gmail.com>>
Cc:
"geotools-gt2-users@lists.sourceforge.net<mailto:geotools-gt2-users@lists.sourceforge.net>"
<geotools-gt2-users@lists.sourceforge.net<mailto:geotools-gt2-users@lists.sourceforge.net>>
Subject: Re: [Geotools-gt2-users] Obtaining physical values from georeferenced
images
On Fri, Aug 1, 2014 at 9:30 AM, andrea antonello
<andrea.antone...@gmail.com<mailto:andrea.antone...@gmail.com>> wrote:
Hi Gaby,
> I am retooling an application that is using a home grown “map” interface,
> replacing the latter with geotools.
> Some of the data comes as georeferenced images. These are created by helper
> tools from CSV files, ESRI bin files or NETCDF files.
>
> All good so far. I can read these files no problem using the
> GridCoverageReader.
>
> All the images produced this way are RGB PNG’s which come with an additional
> file with the extension “range" which gives
> the range of the physical values represented by each pixel. Without this
> information I cannot get pack the physical value at
> each pixel (wind velocity, flood depth, that sort of thing)
Actually apart of being quite a hack, I don't think that you can get
the real value back in every case, don't you?
>From the png you get rgb values in 0-255 ranges. What should happen
next? A mapping to a physical value?
This sounds very strange to me.
Not sure what the range file really contains, though.
Actually the whole coverage model as build originally by M. Desriusseaux was
based on this kind of hack, png images with integer values that are transformed
to a phisical value via a linear transformation, under the assumption that
the quantization occurring in PNG encoding via the palette is not going
to affect significantly the data (e.g., the encoding error is significantly
lower than the sensor error).
The tests in this package provide some examples on how to use these concepts:
https://github.com/geotools/geotools/tree/master/modules/library/coverage/src/test/java/org/geotools/coverage/grid
Basically the idea is that the coverage is build using the png as the rendered
image, and the grid sample
dimensions do contain the transformations to the geophisic interpretation of
the coverage, which
can be obtained as a GridCoveage by getting the geophisics view of it
Cheers
Andrea
--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
GeoTools-GT2-Users mailing list
GeoTools-GT2-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
