[gdal-dev] Fwd: Color Columns in Raster Attribute Tables

[Even Rouault]

Le vendredi 17 janvier 2014 01:21:14, Sam Gillingham a écrit :
> Hi Even, Frank,
> 
> I'm interested to hear if you have an opinion on this. Is this behaviour by
> design or a bug in the HFA driver?
> 
> I'm happy to supply a patch to the HFA driver if you think this is sensible
> solution. I just want to make sure I'm not missing anything...

RAT is not my cup of tea, so I'm not sure to have a particularly enlightened 
opinion on this. It is a bit annoying that the HFA behaviour goes against the 
documentation. AFAIK nobody has ever complained about this, so this might be 
just a sign that RAT is not widely used. Provided that it is documented in 
MIGRATION_GUIDE.TXT, I think it would be OK to make the driver behaviour 
consistant with the doc.
Actually, I'm just thinking to the following point : if the color table in IMG 
is represented as a float, could values that are not of the form N / 255 be 
possible (when generated by Imagine) ?  If so, we would loose information by 
casting to int. It is a bit strange they have selected a floating point 
serialization.
Another possibility would be to indicate the validity range of the attribute, 
e.g 0-255 or 0-1, so that applications can normalize to [0,255] if they need 
to.

> 
> Thanks for your time,
> 
> Sam.
> 
> ---------- Forwarded message ----------
> From: Sam Gillingham <gillingham.sam at gmail.com>
> Date: 14 January 2014 08:51
> Subject: Re: [gdal-dev] Color Columns in Raster Attribute Tables
> To: Ivan Lucena <lucena_ivan at hotmail.com>
> Cc: gdal dev <gdal-dev at lists.osgeo.org>
> 
> 
> 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

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html