Opened 11 years ago

Last modified 5 years ago

#2052 new enhancement

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

Reported by: mlennert Owned by: grass-dev@…
Priority: normal Milestone: 7.6.2
Component: Raster Version: svn-trunk
Keywords: r.in.gdal, rgb Cc:
CPU: Unspecified Platform: Unspecified

Description

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.

Change History (16)

comment:1 by Nikos Alexandris, 11 years ago

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...

comment:2 by hamish, 11 years ago

Component: DefaultRaster
Version: unspecifiedsvn-trunk

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

comment:3 by hamish, 11 years ago

Keywords: r.in.gdal rgb → r.in.gdal, rgb

in reply to:  2 ; comment:4 by mlennert, 11 years ago

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 !

in reply to:  4 ; comment:5 by mmetz, 11 years ago

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?

in reply to:  5 ; comment:6 by mlennert, 11 years ago

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

in reply to:  6 comment:7 by hamish, 11 years ago

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

comment:8 by Nikos Alexandris, 10 years ago

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.

comment:9 by martinl, 8 years ago

Milestone: 7.0.07.0.5

comment:10 by martinl, 8 years ago

Milestone: 7.0.57.3.0

comment:11 by martinl, 8 years ago

Milestone: 7.3.07.4.0

Milestone renamed

comment:12 by neteler, 6 years ago

Milestone: 7.4.07.4.1

Ticket retargeted after milestone closed

comment:13 by neteler, 6 years ago

Milestone: 7.4.17.4.2

comment:14 by martinl, 6 years ago

Milestone: 7.4.27.6.0

All enhancement tickets should be assigned to 7.6 milestone.

comment:15 by martinl, 5 years ago

Milestone: 7.6.07.6.1

Ticket retargeted after milestone closed

comment:16 by martinl, 5 years ago

Milestone: 7.6.17.6.2

Ticket retargeted after milestone closed

Note: See TracTickets for help on using tickets.