r.in.gdal should not by default call first three bands red, green, blue

[mlennert]

Working with multispectral satellite data in tiff where bands are not just red, green, blue, but, for example (for Worldview 2):

1:Coastal
2:Blue
3:Green
4:Yellow
5:Red
6:Red Edge
7:NIR1
8:NIR2

it is a bit annoying that r.in.gdal automatically calls the first three bands .red, .green and .blue. Even in satellite imagery which has only three bands, this does not necessarily mean that they are rgb. Calling them .red, .green and .blue can leave to confusion for the inexperienced user.

I would suggest to remove that functionality and leave it up to the user to decide what the bands represent.

[Nikos Alexandris]

I can only agree that it might confuse people (working these days also with IKONOS, QB and WV2 data).

Also, somewhat related, it seems that in the past, QuickBird delivered data in a different order? See some reference/instructions in the wiki ​http://grasswiki.osgeo.org/wiki/QuickBird#Cleanup.

I will alter the wiki as this is no (longer?) valid -- QuickBird MS bands are in the "expected" order for me (that is B, G, R and NIR) -- and keep it as an extra note in case if...

[hamish]

I'm not 100% sure, but ISTR that it was libgdal doing that, r.in.gdal was just passing the band name along untouched. --> gdal band name detection bug?

It would be bad if the (e.g.) ".blue" band was being named ".red"!

Hamish

ps- trac's parser logic wants keywords separated by commas

[mlennert]

Replying to hamish:

I'm not 100% sure, but ISTR that it was libgdal doing that, r.in.gdal was just passing the band name along untouched. --> gdal band name detection bug?

Replying to hamish:

I'm not 100% sure, but ISTR that it was libgdal doing that, r.in.gdal was just passing the band name along untouched. --> gdal band name detection bug?

Yes and no: GDAL does return a ColorInterp info which is "wrong", but this is apparently due to the original data: ​https://trac.osgeo.org/gdal/ticket/5177

The problem in r.in.gdal is here: ​https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.in.gdal/main.c#L525.

ps- trac's parser logic wants keywords separated by commas

Noted. Thanks for the hint !

[mmetz]

Replying to mlennert:

Replying to hamish:

I'm not 100% sure, but ISTR that it was libgdal doing that, r.in.gdal was just passing the band name along untouched. --> gdal band name detection bug?

Yes and no: GDAL does return a ColorInterp info which is "wrong", but this is apparently due to the original data: ​https://trac.osgeo.org/gdal/ticket/5177

The problem in r.in.gdal is here: ​https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.in.gdal/main.c#L525.

That means the -k flag should be removed and the band number always used as suffix, or optionally the meaning of the -k flag should be reverted such that color names are appended only on request?

[mlennert]

Replying to mmetz:

Replying to mlennert:

Replying to hamish:

I'm not 100% sure, but ISTR that it was libgdal doing that, r.in.gdal was just passing the band name along untouched. --> gdal band name detection bug?

Yes and no: GDAL does return a ColorInterp info which is "wrong", but this is apparently due to the original data: ​https://trac.osgeo.org/gdal/ticket/5177

The problem in r.in.gdal is here: ​https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.in.gdal/main.c#L525.

That means the -k flag should be removed and the band number always used as suffix, or optionally the meaning of the -k flag should be reverted such that color names are appended only on request?

Duh. I have to admit that I completely overlooked this flag. So the question is: what is less confusion for newcomers: have rgb extensions sometimes not be correct, or always only have numbers ?

Moritz

[hamish]

Replying to mlennert:

So the question is: what is less confusion for newcomers: have rgb extensions sometimes not be correct, or always only have numbers ?

I'd go with option (c): complain to the data providers until they correct their files. Better result for everyone in the long run.

rouault:

From the above output, the file must have TIFFTAG_PHOTOMETRIC (wrongly) set to PHOTOMETRIC_RGB. So the problem is more on the producer of the file.

Hamish

[Nikos Alexandris]

This is still unresolved. I did my part for option (c) a year ago, launching an open and direct discussion with a Digital Globe's representative salesman n Europe. No reply in the end.

I still feel that the default import scheme shouldn't take red, green and blue for granted.

[martinl]

Milestone renamed

[neteler]

Ticket retargeted after milestone closed

[martinl]

All enhancement tickets should be assigned to 7.6 milestone.

[martinl]

Ticket retargeted after milestone closed

[martinl]

Ticket retargeted after milestone closed