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 <[email protected]> > Date: 14 January 2014 08:51 > Subject: Re: [gdal-dev] Color Columns in Raster Attribute Tables > To: Ivan Lucena <[email protected]> > Cc: gdal dev <[email protected]> > > > 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 <[email protected]> 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: [email protected] > > To: [email protected] > > 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 > > [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Geospatial professional services http://even.rouault.free.fr/services.html _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
