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

Sat Jan 18 06:18:20 PST 2014

Hi Even,

In a parallel and almost not related topic, I am getting users complains that gdal_translate crashes or waste their time and storage space with some ridiculous RAT that doesn't make any sense for their use case. Maybe we should have a -noRAT option on gdal_translate. I could also add an "RAT2VAT=NO" create-option on GeoRaster driver. 

Any better idea?

Regards,

Ivan

> From: even.rouault at mines-paris.org
> To: gillingham.sam at gmail.com
> Date: Fri, 17 Jan 2014 20:33:21 +0100
> CC: gdal-dev at lists.osgeo.org
> Subject: Re: [gdal-dev] Fwd:  Color Columns in Raster Attribute Tables
> 
> 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
> _______________________________________________
> 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/20140118/d85734c7/attachment.html>