Opened 22 years ago

Last modified 22 years ago

#112 closed defect (worksforme)

gdal - RGB channel order reverted?

Reported by: Markus Neteler Owned by: warmerdam
Priority: high Milestone:
Component: default Version: unspecified
Severity: normal Keywords:
Cc:

Description

> Hi Frank,
>
> sorry to bother your again... [btw: do you prefer that I use the
> gdal list or the bugzilla instead of mailing personally?]
>
> Well, we have a (recent) "problem" with GDAL. It seem that the
> order of RGB channel numbering is reverted. An example:
>
> gdalinfo 043130.tif
> Driver: GTiff/GeoTIFF
> Size is 6720, 5840
> Coordinate System is:
> PROJCS["Monte Mario (Rome) / Italy zone 1",
>     GEOGCS["Monte Mario (Rome)",
>         DATUM["Monte_Mario",
>             SPHEROID["International 1924",6378388,297.000000000005]],
>         PRIMEM["Rome",12.4523333333333],
>         UNIT["degree",0.0174532925199433]],
>     PROJECTION["Transverse_Mercator"],
>     PARAMETER["latitude_of_origin",0],
>     PARAMETER["central_meridian",9],
>     PARAMETER["scale_factor",0.9996],
>     PARAMETER["false_easting",1500000],
>     PARAMETER["false_northing",0],
>     UNIT["metre",1]]
> Origin = (1654040.000000,5123920.000000)
> [...]
> Band 1 Block=6720x1 Type=Byte, ColorInterp=Red
>   Min=0.000/0, Max=255.000/0
>   Overviews: 1344x1168
> Band 2 Block=6720x1 Type=Byte, ColorInterp=Green
>   Min=0.000/0, Max=255.000/0
>   Overviews: 1344x1168
> Band 3 Block=6720x1 Type=Byte, ColorInterp=Blue
>   Min=0.000/0, Max=255.000/0
>   Overviews: 1344x1168
>
> Normally the order is B=1, G=2, R=3 according to the physical spectrum
> (that's common sense in remote sensing, I think).
>
> Probably the problem only appears for r.in.gdal. But I am fairly
> sure that some weeks (?) ago it was B=1, G=2, R=3 and not, as now,
> R=1, G=2, B=3.
>
> Perhaps you can change the order back as it was (and matches the remote
> sensing books). Or is there a particular reason which I am overlooking?
 
Markus,
 
This shouldn't normally happen.  Now that this appears to be a bug, I would
appreciate your creating an entry in bugzilla and including a smallish file
demonstrating the problem.  If you can't provide a small one, then just ftp
a larger one to gdal.velocet.ca/pub/incoming and note this in the bug
report.
I don't want large files (>10MB) loaded into bugzilla.
 
Thanks,


--------------
I have uploaded the GeoTIFF to your incoming/
043130.tfw  043130.tif

PS: Probably it is a good idea to change the read permissions for that
incoming. in /etc/ftpaccess something like
upload /var/ftp /incoming      yes ftp daemon 0440 nodirs
noretrieve /var/ftp/incoming
# Allow on-the-fly compression and tarring
compress        yes             all
tar             yes             all
 
# Prevent anonymous users (and partially guest users)
# from executing dangerous commands
chmod           no              guest,anonymous
delete          no              anonymous
overwrite       no              anonymous
rename          no              anonymous

Change History (1)

comment:1 by warmerdam, 22 years ago

Markus,

I can find no indication of an error with the supplied file.  The
vegetation appears green when loaded in OpenEV indicating that the bands
are properly mapped as far as I can tell.  
Note: See TracTickets for help on using tickets.