<div dir="ltr">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.<br><div class="gmail_extra"><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">dir /b /s *.tif > tiff_list.txt<br></blockquote><div> </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">REM Builds a VRT. A VRT is basically just a XML file saying what all the source tif files are.<br>

gdalbuildvrt -input_file_list tiff_list.txt file.vrt<br></blockquote><div> </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">

REM This is what actually does the mosaicing.<br>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</blockquote>

<div class="gmail_extra"><br></div><div class="gmail_extra">===========</div><div class="gmail_extra"><br></div><div class="gmail_extra">Relating to four bands, I can confirm the PHOTOMETRIC=RGB with JPEG compression does leave the fourth band undefined:</div>

<div class="gmail_extra"><br></div><div class="gmail_extra"><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">

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

</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra">

<br></div><div class="gmail_extra">Thanks again,</div><div class="gmail_extra">Jonathan</div><br><div class="gmail_quote">On 2 December 2013 16:36, Andrew Harfoot <span dir="ltr"><<a 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>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" target="_blank">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<div><div class="h5"><br>
      <br>
      On 02/12/2013 16:30, Jonathan Moules wrote:<br>
    </div></div></div><div><div class="h5">
    <blockquote type="cite">
      
      <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 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 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 alt="Inline images 1"><br>
                                          </div>
                                          <div><br>
                                          </div>
                                          <div>This is what the merged
                                            file looks like (wrong):</div>
                                          <div><img 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 href="mailto:Qgis-user@lists.osgeo.org" target="_blank">Qgis-user@lists.osgeo.org</a>
<a 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 href="tel:%2B44%20%280%2923%208059%202719" value="+442380592719" target="_blank">+44 (0)23 8059 2719</a>
Fax:  <a href="tel:%2B44%20%280%2923%208059%202849" value="+442380592849" target="_blank">+44 (0)23 8059 2849</a>

<a 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 href="mailto:Qgis-user@lists.osgeo.org" target="_blank">Qgis-user@lists.osgeo.org</a><br>
                                <a 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 href="tel:%2B44%20%280%2923%208059%202719" value="+442380592719" target="_blank">+44 (0)23 8059 2719</a>
Fax:  <a href="tel:%2B44%20%280%2923%208059%202849" value="+442380592849" target="_blank">+44 (0)23 8059 2849</a>

<a 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">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 href="tel:%2B44%20%280%2923%208059%202719" value="+442380592719" target="_blank">+44 (0)23 8059 2719</a>
Fax:  <a href="tel:%2B44%20%280%2923%208059%202849" value="+442380592849" target="_blank">+44 (0)23 8059 2849</a>

<a 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>