raster layer properties and mask patches
Bernhard Herzog
bh at intevation.de
Wed Jan 26 17:12:39 CET 2005
Jonathan Coles <jonathan at jpcoles.com> writes:
> 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.
An RGB image has three bands in gdal, one for each color, right? So if
the user specifies an RGB color for the transparent pixels it must not
simply be a color that not used in the image, it must be a color such
that each of its components must be unique in the corresponding band.
That is there must be no color which uses e.g. the same red value as the
special color selected by the user? If so, the situation is even worse
than I thought.
> 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.
It would be much better if they didn't have to do that. Such things
should just work. After all this is something which the computer should
be able to figure out by itself.
> perhaps i don't quite understand what you are saying. could you please
> elaborate what you mean by "special meaning to inband values"?
Any color the user specifies is a valid color value for the image in
principle. "inband" is one adjective I've seen being used for this.
The color value gets a special meaning because it's used to indicate
that all pixels with that value are to be transparent. What should
happen when the image contains all possible color 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.
The projection code knows which pixels have real data. Simplifying a
bit, such algorithms iterate over all output pixels and determine for
each them which pixel in the input image should be mapped to that output
pixel. If the input pixel's coordinates are outside of the input image,
the output pixel has to be transparent. There's no need to encode that
information in the color values. An alpha channel, even if it's just
one bit per pixel, is better.
A bitmap mask is what wxGTK will create anyway. To make matters worse,
AFAICT from the code wxGTK creates the mask bitmap in a simple but quite
inefficient way, calling gdk_image_put_pixel for every pixel.
Bernhard
--
Intevation GmbH http://intevation.de/
Skencil http://skencil.org/
Thuban http://thuban.intevation.org/
More information about the Thuban-devel
mailing list
This site is hosted by Intevation GmbH (Datenschutzerklärung und Impressum | Privacy Policy and Imprint)