From: Martin D. <mar...@no...> - 2005-04-06 12:15:47
|
sim...@ti... a =E9crit : > If i try to display the planar image that is the back end of the grid c= overage > i get a nice image, but when I try to write it to a file or an output s= tream > it fails without throwing an exception. >=20 > Does it have to do with the scaledcolorspace (MARTIN...) ? Maybe. But it depends a lot in which format you try to save the image.=20 Not all formats support floating points; many format just support plain=20 integers. This is very image writer dependent. However, there is some elements: * Images in floating point formats are very usefull for computation, but=20 usually slow to display and not accepted by many image writer plugins. * Images with integer pixels are much faster to display (usually=20 hardward accelerated) and supported by most image writer plugins, but=20 inconvenient for computations purpose. It is hard to have the advantage of both world in same time (I tried=20 very hard!). I have not found any better way than managing two versions=20 of the same image: a floating point version for computations, and an=20 integer versions for display / saving in PNG, JPEG, etc. It sound like a waste of memory, but actually not that much. Remember=20 that JAI images are tiled and the default JAI's TileCache is limited to=20 16Mb. If yours real data are floating points, the integer versions will=20 be computed only for the requested tiles, and conversely. So if we have to live with a floating point and an integer versions of=20 ours data, GridCoverage2D tries to make the switch between those two=20 versions as easy as possible. This is 'GridCoverage.geophysics(boolean)'=20 jobs. - geophysics(true) returns the floating point version, usefull for computation. Note that this version often uses a custom ColorSpace, otherwise the image can't be display as-is (I try to supports display of floating point version even if integer version are more suitable for display). - geophysics(false) returns the integer version, usefull for fast display and saving to disk. Note that this version uses a standard J2SE ColorSpace, so it should work with most ImageWriter plugins. However, 'geophysics(boolean)' will work only if you teach it how to=20 convert between floating point and integer values. This is usually done=20 with a linear conversion of the form "value * scale + offset". In the=20 "OpenGIS GridCoverage Implementation specification 1.0", this linear=20 relationship was specified through 'getScale()' and 'getOffset()'=20 attributes in the SampleDimension interface. In Geotools implementation,=20 I generalized it to an arbitrary MathTransform1D, in order to support=20 logarithmic conversions like the one used in remote sensing images of=20 oceanographic chlorophylle-a concentrations. An other difference between OpenGIS specification and Geotools=20 implementation is that Geotools allows to specifies 'scale' and 'offset'=20 attributes at a finer grain than OpenGIS. The OpenGIS specification put=20 'scale' and 'offset' attributes in the SampleDimension interface (as=20 explained in previous paragraph). Geotools put them in Category, which=20 is included in SampleDimension. You can specifie 'scale' and 'offset' attributes explicitly (which I=20 recommand if you want an uniform look for all images of the same type,=20 for example all sea surface temperature (SST) images), or you can=20 compute it dynamically. Below is an example of dynamic computation: Category values, nan; values =3D new Category("values", new Color[] {Color.BLUE, Color.GREEN, Color.RED}, new NumberRange(1, 255), new NumberRange(arcGridRaster.getMinValue(), arcGridRaster.getMaxValue())) nan =3D new Category("nodata", Color.BLACK, 0); The first category ("values") means that floating point (geophysics)=20 values range from 'arcGridRaster.getMinValue()' to=20 'arcGridRaster.getMaxValue()', and you decide to allocate them integer=20 values 1 to 255 inclusive. The linear relationship from the floating=20 points values to the integer values (i.e. the above-cited 'scale' and=20 'offset' attributes) will be computed automatically. The second category ("nodata") means that you allocate one slot for=20 "nodata" (you could have many slots if you want, for example a different=20 slot for data masked by clouds), and this slots will have the integer=20 value 0. Geotools will automatically maps this integer value to NaN in=20 the floating point version. Note: if you specifie integer values in a range not greater than 0-255,=20 Geotools will uses a 8-bits IndexColorModel for the integer version of=20 RenderedImage. Otherwise, if the integer values are in a range not=20 greater than 0-65535, then Geotools will uses a 16-bits IndexColorModel. Hope it help, Martin. |