raster layer properties and mask patches
Jonathan Coles
jonathan at jpcoles.com
Wed Jan 26 16:17:27 CET 2005
Am Mittwoch, den 26.01.2005, 15:57 +0100 schrieb Bernhard Herzog:
> Jonathan Coles <jonathan at jpcoles.com> writes:
>
> > o The mask color and whether or not the mask should be used
> > are saved in the .thuban file.
>
> Do we have to use a color for the mask? Giving special meaning to
> inband values (i.e. values that are not per se special) always feels
> like a crutch to me. A real bitmap for a mask would be better IMO.
gdal specifically requests values for each band for NO_DATA values. when
it projects an image, the output is initialized to the NO_DATA values.
any part of the output that is not real data will retain the NO_DATA
value for a particular band.
the values that the user selects are not special in and of themselves,
other than they supposedly aren't used in the original image. that is
why it is necessary to have the user select a color. or perhaps the user
*does* want to use a color that's already in the image. for example, you
can make most of the ocean disappear in the iceland image by selecting
index 9 as the mask.
perhaps i don't quite understand what you are saying. could you please
elaborate what you mean by "special meaning to inband values"? there
must be a way to distinquish between what is real data and what should
be part of the mask. even if you were to use a bitmap for the mask, the
bitmap would have to be created by distinquishing between real and false
data.
now, as the code is written, it accepts a color (#rrggbb) or an index. i
have been thinking that instead of storing the values as a hex string it
would be better to store each individual value in a list (e.g.
[rr,gg,bb]) because i don't think that we are guaranteed that the values
are all 0-255 (at least the indices).
--jonathan
--
=====================================================================
Jonathan Coles http://www.jpcoles.com
jonathan at jpcoles.com GnuPG Key: /gpg_pub_key.asc
=====================================================================
More information about the Thuban-devel
mailing list
This site is hosted by Intevation GmbH (Datenschutzerklärung und Impressum | Privacy Policy and Imprint)