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
Note:
See TracTickets
for help on using tickets.