[gdal-dev] Color Columns in Raster Attribute Tables

[Sam Gillingham]

Hi Ivan,

Unfortunately the color table API does not support the functionality that
was added to the RAT API in RFC40. As a result, dealing with large color
tables can be problematic.

Yes the HFA driver does report colors correctly as 0-255 with the color
table API and one solution could be to add RFC40 functionality to the color
table API. However, it does seem that it does make sense to be able to
manipulate colors from the RAT API for e.g. setting colors based on the
value(s) found in other attribute columns easily.

I accept that no consistency can be expected for user defined columns
(usage == GFU_Generic) but I would have though applications could depend on
the color columns since they are marked as such by their usage. In fact the
documentation for the usage values (
http://www.gdal.org/gdal_8h.html#a27bf786b965d5227da1acc2a4cab69a1) does
specify them to be 0-255 so this seems to have been the intention and is
maybe just a bug in the HFA driver.

Sam.


On 13 January 2014 15:18, Ivan Lucena <lucena_ivan at hotmail.com> wrote:

> Hi Sam,
>
> In GDAL color table is supported by the GDALColorTable
> http://gdal.org/classGDALColorTable.html not by GDALRasterAttributeTable
> http://gdal.org/classGDALRasterAttributeTable.html.
>
> The GDALColorTable is a little bit limited but it is pretty much
> consistent across all the drivers that support it. For example, when you
> say that HFA reports RGBA with values from 0..1 as RAT it probably reports
> the correct 0..255 as GDALGetColorTable or it doesn't report it at all,
> because of the GDALColorTable limitation, like data type or number of
> colors.
>
> But IMHO, there is no reason to expect consistency on the representation
> of color table from a driver RAT. An RAT could be user defined or generated
> by some driver or application.
>
> What you are seem is that some drivers are using, or maybe abusing, the
> freedom format of RAT to report information than can be understood by some
> particular application or software (mea culpa on one of those).
>
> Best regards,
>
> Ivan
>
> ------------------------------
> Date: Mon, 13 Jan 2014 13:06:01 +1300
> From: gillingham.sam at gmail.com
> To: gdal-dev at lists.osgeo.org
> Subject: [gdal-dev] Color Columns in Raster Attribute Tables
>
>
> Hi List,
>
> There appears to be an inconsistency in the way color columns are handled
> within Raster Attribute Tables (RATs) by different drivers. Color columns
> are currently identified by their 'usage' setting - GFU_Red, GFU_Green,
> GFU_Blue and GFU_Alpha. The HFA driver presents color columns as doubles
> between 0 and 1 as this is how they are stored in the file. The IDRISI
> driver presents them as integers between 0 and 255 like the Color Table
> API. Code that uses color columns from the RAT API currently needs to know
> which driver it is using, defeating one of the aims of GDAL.
>
> I propose that the RAT API be defined so that color columns always appear
> as Integer 0-255 no matter what type and range they are stored as. This
> would make the RAT API consistent with the Color Table API and would mean a
> change to the HFA driver
>
> Another option is that flags are added to the RAT SetValue, GetValueAs*
> and ValuesIO calls to specify the conversion to/from the native type. This
> seems a bigger change.
>
> Any thoughts?
>
> Sam.
>
> _______________________________________________ gdal-dev mailing list
> gdal-dev at lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140114/4b3fb736/attachment.html>