<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Interesting!<br>
<br>
Just found that you can override the GDAL behaviour of adding
alpha interpretation (this is the default as described in the
GTiff format spec <a href="http://www.gdal.org/frmt_gtiff.html">here
</a>) by adding the GDAL -co command PHOTOMETRIC=RGB. Not sure how
this tallys with the YCBCR colour model used by JPEG though?<br>
<br>
Cheers,<br>
<br>
Andy<br>
<br>
On 02/12/2013 16:30, Jonathan Moules wrote:<br>
</div>
<blockquote
cite="mid:CAA-xNcVY8+T=so+rXWPbyeNX_+jSM_1naU94r8+X0HLjoNhVkA@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div dir="ltr">
<div class="gmail_extra">
<div>Hi Andy,</div>
<div>I guess that makes sense.</div>
<div><br>
</div>
<div>Relating to gdalwarp:</div>
<div>- Output files by default are larger than gdal_merge.</div>
<div>- 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!</div>
<div>- gdal_merge seems to do something that results in some
heavy blurring when using -co PHOTOMETRIC=YCBCR - this
doesn't happen with gdalwarp.</div>
<div><br>
</div>
<div>So the optimal filesize for an aerial photograph is
rendered with something like:</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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</blockquote>
<div><br>
</div>
<div>I've not tried the four-band stuff again; just trying to
optimise by 3-band.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Jonathan</div>
<br>
<br>
<div class="gmail_quote">On 2 December 2013 16:10, Andrew
Harfoot <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:ajph@geodata.soton.ac.uk" target="_blank">ajph@geodata.soton.ac.uk</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>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!).<br>
<br>
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 :(<br>
<br>
Cheers,<br>
<br>
Andy
<div>
<div><br>
<br>
On 02/12/2013 16:00, Jonathan Moules wrote:<br>
</div>
</div>
</div>
<div>
<div>
<blockquote type="cite">
<div dir="ltr">Hi Andy,
<div>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. :-)<br>
<div class="gmail_extra">
<div><br>
</div>
<div>====</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Many thanks!<br>
Jonathan</div>
<br>
<br>
<div class="gmail_quote">On 2 December 2013
15:48, Andrew Harfoot <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ajph@geodata.soton.ac.uk"
target="_blank">ajph@geodata.soton.ac.uk</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>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!
<div><br>
<br>
Cheers,<br>
<br>
Andy<br>
<br>
On 02/12/2013 11:53, Jonathan
Moules wrote:<br>
</div>
</div>
<blockquote type="cite">
<div>
<div>
<div dir="ltr">Hi List,
<div>I've got a 4 band raster
aerial photography (RGBI)
that comprises lots of
tiles. I've merged some of
the tiles together with:</div>
<div><br>
</div>
<blockquote
class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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</blockquote>
<div><br>
</div>
<div>But the resultant file
looks funny in QGIS.</div>
<div>This is what the source
file looks like (correct):</div>
<div><img
moz-do-not-send="true"
alt="Inline images 1"><br>
</div>
<div><br>
</div>
<div>This is what the merged
file looks like (wrong):</div>
<div><img
moz-do-not-send="true"
alt="Inline images 2"><br>
</div>
<div><br>
</div>
<div>All the shadows are a
whitey colour. This doesn't
happen with 3-band (RGB)
images.</div>
<div>I've tried comparing
individual bands; they all
look different in the
4-band.</div>
<div><br>
</div>
<div>However, if I open the
four-band in ArcGIS, it
looks fine (both source and
original).</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Jonathan</div>
</div>
<br>
</div>
</div>
<div><span
style="color:rgb(34,34,34);font-family:arial,sans-serif">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.</span> <br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Qgis-user mailing list
<a moz-do-not-send="true" href="mailto:Qgis-user@lists.osgeo.org" target="_blank">Qgis-user@lists.osgeo.org</a>
<a moz-do-not-send="true" href="http://lists.osgeo.org/mailman/listinfo/qgis-user" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-user</a></pre>
</div>
</blockquote>
<div> <br>
<br>
<pre cols="72">--
Andy Harfoot
GeoData Institute
University of Southampton
Southampton
SO17 1BJ
Tel: <a moz-do-not-send="true" href="tel:%2B44%20%280%2923%208059%202719" value="+442380592719" target="_blank">+44 (0)23 8059 2719</a>
Fax: <a moz-do-not-send="true" href="tel:%2B44%20%280%2923%208059%202849" value="+442380592849" target="_blank">+44 (0)23 8059 2849</a>
<a moz-do-not-send="true" href="http://www.geodata.soton.ac.uk" target="_blank">www.geodata.soton.ac.uk</a>
</pre>
</div>
</div>
<br>
_______________________________________________<br>
Qgis-user mailing list<br>
<a moz-do-not-send="true"
href="mailto:Qgis-user@lists.osgeo.org"
target="_blank">Qgis-user@lists.osgeo.org</a><br>
<a moz-do-not-send="true"
href="http://lists.osgeo.org/mailman/listinfo/qgis-user"
target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-user</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
<span
style="color:rgb(34,34,34);font-family:arial,sans-serif">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.</span> </blockquote>
<br>
<br>
<pre cols="72">--
Andy Harfoot
GeoData Institute
University of Southampton
Southampton
SO17 1BJ
Tel: <a moz-do-not-send="true" href="tel:%2B44%20%280%2923%208059%202719" value="+442380592719" target="_blank">+44 (0)23 8059 2719</a>
Fax: <a moz-do-not-send="true" href="tel:%2B44%20%280%2923%208059%202849" value="+442380592849" target="_blank">+44 (0)23 8059 2849</a>
<a moz-do-not-send="true" href="http://www.geodata.soton.ac.uk" target="_blank">www.geodata.soton.ac.uk</a>
</pre>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<span
style="color:rgb(34,34,34);font-family:arial,sans-serif;background-color:rgb(255,255,255)">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.</span>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Andy Harfoot
GeoData Institute
University of Southampton
Southampton
SO17 1BJ
Tel: +44 (0)23 8059 2719
Fax: +44 (0)23 8059 2849
<a class="moz-txt-link-abbreviated" href="http://www.geodata.soton.ac.uk">www.geodata.soton.ac.uk</a>
</pre>
</body>
</html>