[Qgis-user] Four band raster displaying funny

[Jonathan Moules]

Further testing indicates that the same (optimal) result can be had using a
combination of a vrt and gdal_translate without having to manually bother
with memory management.

dir /b /s *.tif > tiff_list.txt
>


> REM Builds a VRT. A VRT is basically just a XML file saying what all the
> source tif files are.
> gdalbuildvrt -input_file_list tiff_list.txt file.vrt
>


> REM This is what actually does the mosaicing.
> gdal_translate -of GTiff -co TILED=YES -co BIGTIFF=YES -co COMPRESS=JPEG
> -co JPEG_QUALITY=80 -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 -co
> PHOTOMETRIC=YCBCR file.vrt file.tif


===========

Relating to four bands, I can confirm the PHOTOMETRIC=RGB with JPEG
compression does leave the fourth band undefined:

Band 1 Block=512x512 Type=Byte, ColorInterp=Red
> Band 2 Block=512x512 Type=Byte, ColorInterp=Green
> Band 3 Block=512x512 Type=Byte, ColorInterp=Blue
> Band 4 Block=512x512 Type=Byte, ColorInterp=Undefined


The filesize is the same as setting no photometric flag. So that seems to
be the solution, at least where QGIS is concerned with 4 bands.

Thanks again,
Jonathan

On 2 December 2013 16:36, Andrew Harfoot <ajph at geodata.soton.ac.uk> wrote:

>  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> 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>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):
>>> [image: Inline images 1]
>>>
>>>  This is what the merged file looks like (wrong):
>>> [image: 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 listQgis-user at lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/qgis-user
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>>
>>> _______________________________________________
>>> Qgis-user mailing list
>>> 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
>> Fax:  +44 (0)23 8059 2849
>> 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
>
>

-- 
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20131202/9768def7/attachment.html>