[udig-devel] Re: [-DETECTION SPAM-] [Geotools-devel] Re: Raster Data Ima

[simone giannecchini <simboss1@xxxxxxxxx>]

You already explained me this Martin but I think it has been a good
idea to state it again clearly because not everybody might have clear
in mind the difference between geophyisc and non geophysic.

The point of what I am saying is that sometimes I simply do not need
the non geophysic view, since the geophysic data comes in a format
that I am able to show as it is. This is the case with world images.
In my organization sometimes I receive images having a RGBA color
space with 24 bit per channel, or geotiff in gray scale but with 16,
24 or 32 bits of depth. The point is that, especially when having a
multiband image, it is uncorrect to build a non geophysic view for a
couple of reasons ranging from the fact that I would loose the
multiband nature of them (and this is an issue of the contruction of
the color model)  to the fact that I really do not have a difference
between the geophysic and non-geophyisic view.

In such a case having a simple hint that allowed me to control the
automatic creation of a non-geophysic view would really be of help!
Besides this, I do think that everything that is automatic and
involves creation of a "view" of data should provide the user with a
mean to control this process. It is somehow annoying that I cannot
(well sometimes is possible via the hint on the SampleDimensionType)
avoid the creation of a non-geophysic view, since the code tha relies
on my code could not be able to know when to call geophysic(..) with
true instead of false.

This comes in the path when we try to show geotiff or world images in
the WMS via the WCS which relies on GC2D and GridCoverageRenderer. If
you have a 32 bit grayscale geotiff the WMS will show its
non-geophysic counterpart, since it always assumes that the
non-geophysic view is the one to use (and I agree with this), but this
might be a real issue, because I get an image that has lower fidelity
than expected and if I start to zoom I get  images of quality worse
than expected (trust me in this, people seeing the WMS at work
objected that!).

I implemented what I said adding a Hint to the geotools factory class
and some new constructors to GC2D that allow you to provide hint when
you build a GC2D using a RenderedImage. In case yout ask, via the
hint, to NOT create a non-geophyisic view, I simply state that the
transformation between sampleValueRange and GeophysicValueRange is the
identity, therefore geophysic and non-geophysic view are coincident.
I will put that in a branch as soon as possible.

Simone.
On 5/15/05, Martin Desruisseaux <martin.desruisseaux@xxxxxxxxxxxxx> wrote:
> simone giannecchini a écrit :
> > The problem I ran into is that when I create a grid
> > coverage from a REAL buffered image (which means not just a container
> > for FLOAT, DOUBLE or other geophisic data) the GridCoverage2D class
> > automatically tries to create a non geophysisc view of it.
> 
> You should be able to control a non-geophysics view...
> 
> Reminder (for peoples not familiar to this geophysics stuff in
> GridCoverage):
> 
>   - "geophysics" image contains "real world" values (e.g. sea surface
>     temperature in °C) to be used for computation. Pixel values in
>     "geophysics" are usually (but not required) floating-point numbers.
> 
>   - "non-geophysics" image pack the values into integers. Those integers
>     are related to the "real world" values (i.e. "geophysics") through
>     OpenGIS's 'scale', 'offset' and 'nodata' attributes (defined in OGC
>     specification). The "non-geophysics" image is usually much more
>     efficient for rendering.
> 
> If you are creating an image from "real world" data (e.g. temperature in
> °C), then you can create the "geophysics" image and let Geotools creates
> the "non-geophysics" image on the fly.
> 
> If you are creating an image from "packed" data (usually integer
> values), then you can create the "non-geophysics" image and let Geotools
> creates the "geophysics" image on the fly.
> 
> In other words, "geophysics" and "non-geophysics" images are always
> together; they are two representations of the same data (the first one
> more appropriate for computation, the second one more appropriate for
> display). You create one of them, and Geotools create the other one on
> the fly only if needed. "One of them" do not means "the geophysics one".
> It work in both direction. You can create the "non-geophysics" one instead.
> 
> Steps to follow: creates the categories with the range of pixel values
> in the "non-geophysics" image (or packed image), and the transformation
> formula for converting the integers to "real world" values. E.g.:
> 
>   new Category("Temperature", colors, 1, 256, 0.15, -5)
> 
> Uses pixel values 1 to 255 inclusive for temperature, to be translated
> into "real world" values using the formula 0.15*pixel - 5. Note that at
> this stage, we do not specify if pixels are really packed as integer in
> the range 1 to 255, or if they are already temperature °C to be packed.
> Category works in both ways.
> 
> Next, constructs a SampleDimension with all categories.
> 
> Finally, *before* to give the SampleDimension to GridCoverage, there is
> where you make a choice:
> 
> - If your original image is a geophysics one to be translated into
>   a non-geophysics one using the *inverse* of the formula given in
>   Category, give SampleDimension.geophysics(true) to the GridCoverage2D
>   constructor.
> 
> - If your original image is a non-geophysics one to be translated into
>   a geophysics one using the *direct* formula given in Category, give
>   SampleDimension.geophysics(false) to GridCoverage2D constructor.
>   Actually, you could omit geophysics(false) since it is the default.
> 
> If you give geophysics SampleDimensions to GridCoverage2D, you will get
> a geophysics coverage. If you give non-geophysics SampleDimensions to
> GridCoverage2D, you will get a non-geophysics coverage.
> 
> Does it work, or did I missed something?
> 
>        Martin.
> 
>