[Qgis-user] Four band raster displaying funny

Mon Dec 2 08:36:12 PST 2013

Interesting!

Just found that you can override the GDAL behaviour of adding alpha 
interpretation (this is the default as described in the GTiff format 
spec here <http://www.gdal.org/frmt_gtiff.html>) by adding the GDAL -co 
command PHOTOMETRIC=RGB. Not sure how this tallys with the YCBCR colour 
model used by JPEG though?

Cheers,

Andy

On 02/12/2013 16:30, Jonathan Moules wrote:
> Hi Andy,
> I guess that makes sense.
>
> Relating to gdalwarp:
> - Output files by default are larger than gdal_merge.
> - But they can be much smaller. You have to set *both*  -wm and 
> --config GDAL_CACHEMAX - if you only set -wm, then the file is 
> actually larger!
> - gdal_merge seems to do something that results in some heavy blurring 
> when using -co PHOTOMETRIC=YCBCR - this doesn't happen with gdalwarp.
>
> So the optimal filesize for an aerial photograph is rendered with 
> something like:
>
>     gdalwarp -of GTiff -wm 9999 --config GDAL_CACHEMAX 9999 -co
>     TILED=YES -co BIGTIFF=YES -co COMPRESS=JPEG -co JPEG_QUALITY=80
>     -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 -co PHOTOMETRIC=YCBCR
>     input1.tif input2.tif output.tif
>
>
> I've not tried the four-band stuff again; just trying to optimise by 
> 3-band.
>
> Thanks,
> Jonathan
>
>
> On 2 December 2013 16:10, Andrew Harfoot <ajph at geodata.soton.ac.uk 
> <mailto:ajph at geodata.soton.ac.uk>> wrote:
>
>     I think QGIS is innocent in this - if a band is set as an alpha
>     channel then it should be handled as such by default in a viewer
>     (so mark down Arc for not using the alpha information!).
>
>     GDAL is the culprit as it is adding the alpha interpretation
>     without being prompted. I have just replicated this with some RGBI
>     imagery myself: prior to passing through GDAL's hands the IR band
>     is present, but isn't interpreted as an alpha channel. I can't get
>     the -setci switch to do anything though :(
>
>     Cheers,
>
>     Andy
>
>
>     On 02/12/2013 16:00, Jonathan Moules wrote:
>>     Hi Andy,
>>     Yep, that was it. I didn't know QGIS could do that; another good
>>     example of software trying to be "smart" and confusing the poor
>>     user. :-)
>>
>>     ====
>>
>>     I didn't know gdalwarp could do mosaicing too. I'll have to test
>>     it. I'll ask on the gdal list if I want to try the -setci parameter.
>>
>>     Many thanks!
>>     Jonathan
>>
>>
>>     On 2 December 2013 15:48, Andrew Harfoot
>>     <ajph at geodata.soton.ac.uk <mailto:ajph at geodata.soton.ac.uk>> wrote:
>>
>>         PS. gdalwarp offers more flexibility when mosaicing rasters,
>>         and is better at memory management. I have just noticed that
>>         in GDAL 1.10 and above there is an gdalwarp option -setci
>>         that 'Sets the color interpretation of the bands of the
>>         target dataset from the source dataset'. This could be used
>>         to remove the assignment of the alpha channel to the IR band
>>         on merging. Sadly there isn't an example of its usage!
>>
>>
>>         Cheers,
>>
>>         Andy
>>
>>         On 02/12/2013 11:53, Jonathan Moules wrote:
>>>         Hi List,
>>>         I've got a 4 band raster aerial photography (RGBI) that
>>>         comprises lots of tiles. I've merged some of the tiles
>>>         together with:
>>>
>>>             gdal_merge -o 1.tif -of GTiff -co TILED=YES -co
>>>             BIGTIFF=YES -co COMPRESS=JPEG -co JPEG_QUALITY=50 -co
>>>             BLOCKXSIZE=512 -co BLOCKYSIZE=512 --optfile tiff_list.txt
>>>
>>>
>>>         But the resultant file looks funny in QGIS.
>>>         This is what the source file looks like (correct):
>>>         Inline images 1
>>>
>>>         This is what the merged file looks like (wrong):
>>>         Inline images 2
>>>
>>>         All the shadows are a whitey colour. This doesn't happen
>>>         with 3-band (RGB) images.
>>>         I've tried comparing individual bands; they all look
>>>         different in the 4-band.
>>>
>>>         However, if I open the four-band in ArcGIS, it looks fine
>>>         (both source and original).
>>>
>>>         Anyone know what's going on? Is it a QGIS bug or is it doing
>>>         something "smart"; I can't see anything odd going on with
>>>         symbology.
>>>
>>>         Thanks,
>>>         Jonathan
>>>
>>>         This transmission is intended for the named addressee(s)
>>>         only and may contain sensitive or protectively marked
>>>         material up to RESTRICTED and should be handled accordingly.
>>>         Unless you are the named addressee (or authorised to receive
>>>         it for the addressee) you may not copy or use it, or
>>>         disclose it to anyone else. If you have received this
>>>         transmission in error please notify the sender immediately.
>>>         All email traffic sent to or from us, including without
>>>         limitation all GCSX traffic, may be subject to recording
>>>         and/or monitoring in accordance with relevant legislation.
>>>
>>>
>>>         _______________________________________________
>>>         Qgis-user mailing list
>>>         Qgis-user at lists.osgeo.org  <mailto:Qgis-user at lists.osgeo.org>
>>>         http://lists.osgeo.org/mailman/listinfo/qgis-user
>>
>>
>>         -- 
>>         Andy Harfoot
>>
>>         GeoData Institute
>>         University of Southampton
>>         Southampton
>>         SO17 1BJ
>>
>>         Tel:+44 (0)23 8059 2719  <tel:%2B44%20%280%2923%208059%202719>
>>         Fax:+44 (0)23 8059 2849  <tel:%2B44%20%280%2923%208059%202849>
>>
>>         www.geodata.soton.ac.uk  <http://www.geodata.soton.ac.uk>
>>
>>
>>         _______________________________________________
>>         Qgis-user mailing list
>>         Qgis-user at lists.osgeo.org <mailto:Qgis-user at lists.osgeo.org>
>>         http://lists.osgeo.org/mailman/listinfo/qgis-user
>>
>>
>>
>>     This transmission is intended for the named addressee(s) only and
>>     may contain sensitive or protectively marked material up to
>>     RESTRICTED and should be handled accordingly. Unless you are the
>>     named addressee (or authorised to receive it for the addressee)
>>     you may not copy or use it, or disclose it to anyone else. If you
>>     have received this transmission in error please notify the sender
>>     immediately. All email traffic sent to or from us, including
>>     without limitation all GCSX traffic, may be subject to recording
>>     and/or monitoring in accordance with relevant legislation. 
>
>
>     -- 
>     Andy Harfoot
>
>     GeoData Institute
>     University of Southampton
>     Southampton
>     SO17 1BJ
>
>     Tel:+44 (0)23 8059 2719  <tel:%2B44%20%280%2923%208059%202719>
>     Fax:+44 (0)23 8059 2849  <tel:%2B44%20%280%2923%208059%202849>
>
>     www.geodata.soton.ac.uk  <http://www.geodata.soton.ac.uk>
>
>
>
> This transmission is intended for the named addressee(s) only and may 
> contain sensitive or protectively marked material up to RESTRICTED and 
> should be handled accordingly. Unless you are the named addressee (or 
> authorised to receive it for the addressee) you may not copy or use 
> it, or disclose it to anyone else. If you have received this 
> transmission in error please notify the sender immediately. All email 
> traffic sent to or from us, including without limitation all GCSX 
> traffic, may be subject to recording and/or monitoring in accordance 
> with relevant legislation. 

-- 
Andy Harfoot

GeoData Institute
University of Southampton
Southampton
SO17 1BJ

Tel:  +44 (0)23 8059 2719
Fax:  +44 (0)23 8059 2849

www.geodata.soton.ac.uk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20131202/1b25a18e/attachment.html>