#2052: r.in.gdal should not by default call first three bands red, green, blue
---------------------------+------------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: r.in.gdal rgb | Platform: Unspecified
Cpu: Unspecified |
---------------------------+------------------------------------------------
Working with multispectral satellite data in tiff where bands are not just
red, green, blue, but, for example (for Worldview 2):
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.
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...
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
#2052: r.in.gdal should not by default call first three bands red, green, blue
----------------------------+-----------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Raster | Version: svn-trunk
Keywords: r.in.gdal, rgb | Platform: Unspecified
Cpu: Unspecified |
----------------------------+-----------------------------------------------
Comment(by mlennert):
Replying to [comment:2 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 [comment:2 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?
#2052: r.in.gdal should not by default call first three bands red, green, blue
----------------------------+-----------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Raster | Version: svn-trunk
Keywords: r.in.gdal, rgb | Platform: Unspecified
Cpu: Unspecified |
----------------------------+-----------------------------------------------
Comment(by mmetz):
Replying to [comment:4 mlennert]:
> Replying to [comment:2 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\]
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?
#2052: r.in.gdal should not by default call first three bands red, green, blue
----------------------------+-----------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Raster | Version: svn-trunk
Keywords: r.in.gdal, rgb | Platform: Unspecified
Cpu: Unspecified |
----------------------------+-----------------------------------------------
Comment(by mlennert):
Replying to [comment:5 mmetz]:
> Replying to [comment:4 mlennert]:
> > Replying to [comment:2 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 ?
#2052: r.in.gdal should not by default call first three bands red, green, blue
----------------------------+-----------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Raster | Version: svn-trunk
Keywords: r.in.gdal, rgb | Platform: Unspecified
Cpu: Unspecified |
----------------------------+-----------------------------------------------
Comment(by hamish):
Replying to [comment:6 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.
#2052: r.in.gdal should not by default call first three bands red, green, blue
----------------------------+-----------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Raster | Version: svn-trunk
Keywords: r.in.gdal, rgb | Platform: Unspecified
Cpu: Unspecified |
----------------------------+-----------------------------------------------
Comment(by nikosa):
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.