[Landsat-pds] Landsat-pds Digest, Vol 2, Issue 4

Thu Feb 26 08:24:27 PST 2015

I am fine with tiling. I wrote earlier that in my less than scientific approach I typically use 512 tiles size which is the same as Peter's recommendation.
We just need to make sure we do not alter any original pixel values and that gdalinfo reports the same precision etc 
-Mark 

-----Original Message-----
From: Sundwall, Jed 
Sent: Wednesday, February 25, 2015 2:45 PM
To: Peter Becker
Cc: Korver, Mark; landsat-pds at lists.osgeo.org
Subject: Re: [Landsat-pds] Landsat-pds Digest, Vol 2, Issue 4

I’m +1 for adding tiling to scenes, and I’d submit a pull request to add them, but I don’t know how!

Does anyone else want to weigh in on this? I think Peter’s made a good case here, and tiling appears to open up enough possibilities that outweigh any potential downsides.

Jed.

> On Feb 10, 2015, at 7:31 PM, Peter Becker <pbecker at esri.com> wrote:
> 
> Mark
> 
> I still maintain the tiling the imagery will have significant benefits for its use. One of the key aspects of the Landsat 8 processing is that each scene is orthorectified to specific UTM zones. Great effort was also put by USGS to ensure high pixel accuracy. As a result it is relatively easy for applications to perform temporal analysis of the imagery. Much of such analysis is an Area of interest basis and not a scene basis. Having data non tiled, significantly increase the data read.
> As a minor aside: The tiling also improves the compression a bit (about 2%). The current method of compressing each line of the scene separately means that Deflate is not quite as efficient as when compressing a tile of imagery. Also the number of offsets in the TIF files is significantly reduced. Currently there is an offset and deflate header stored for every line (strip) IE about 7800 of them vs only about 250 of them if using tiled 512.
> 
> Frank did a great comparison on the compression 
> (https://github.com/landsat-pds/landsat_ingestor/blob/master/Compressi
> on.md) He shows the slight benefit of in compression for tiling.
> I would like to expand on the one part in which he states:
> =============="
> Using either bigger strips or tiling has compression benefits, and 
> will be supported by clients, but is does have performance implications for different data processing flows. Simple viewers will often be able to show downsampled images quickly when the strip size is one line because they just pull the subset of lines they need. Big strips or tiles means they have to essentially scan all the data. Tiling is great for subregion requests (perhaps from a mapping server) but less ideal for serial processing software that is going line by line. Overall, the organization options didn't give that much difference in size, so we should likely consider the performance of utilization issues before finalizing a decision "===============
> The down sampling being referred to here is to read every say X lines to provide such a down sampled image. Eg for 1/10 sale read every 10 lines. With strip based compression, this still requires reading 1/10 of the data and requires a lot of data requests (approx 780). What I am recommending (in a separate thread) is that we include overviews (.OVR) . In this case the application could read the nearest appropriate overview and display that instead. In this specific example the data volume to read an image at 1/10 the resolution would be 1/81   (1/9x9) and be achieved in 4 range requests. That's a lot faster and simpler. Tiling TIF files is just as much of the TIF standard as strip wise compression.
> 
> Tiling the imagery will have very little if any detrimental effect on any application reading the whole file. If anything it will make it faster. In the vast majority of cases having the imagery tiled will significantly improve access performance, by allowing only the required part of the scene to be read. I therefore recommend that this is changed to Tiled sooner than later.
> 
> Concerning the Latency question. I agree with you the 'Latency' is primarily for the first request, there after the requests are fast.
> I see no reason why applications should not be doing 'range gets' to S3. GDAL already supports this using VSICurl.
> 
> _Peter
> 
> -----Original Message-----
> From: landsat-pds-bounces at lists.osgeo.org 
> [mailto:landsat-pds-bounces at lists.osgeo.org] On Behalf Of Korver, Mark
> Sent: Friday, February 06, 2015 3:48 PM
> To: landsat-pds at lists.osgeo.org
> Subject: Re: [Landsat-pds] Landsat-pds Digest, Vol 2, Issue 4
> 
> Normally when I am working with large TIFF files I will check to see their structure and if not tiled I will internally tile them to the same 512x512 that Peter mentions. That assumes clients are typically looking at parts of the TIFF file, which is true if we are just trying to speed up a WMS server.
> In that sense the 512 rings true to me, but having gone back and read Frank's words on the landsat ingestor process, I can see that the 512 is my typical use-case and maybe not someone else's best practice for sat scenes. 
> In fact, now that I think about it, I just saw a great demo yesterday? (seems like yesterday) where the whole point was interactive coding that was processing multiple L8 bands, and not some part of scene, but the whole scene, or scenes. Not sure about this but that code is probably quite happy with no tiles.
> 
> Also, I would disagree on tiling for latency reasons. I don't think we will be doing range gets to S3 for this data. With what I saw yesterday and what I do with aerial imagery, the first request for the L8 band or aerial image might have some latency due to having to get the file off of S3, but subsequent requests will be to a cached copy on SSD 'local' to the EC2 instance.
> Also, latency is an interesting question with S3. From the individual compute node perspective the first request will be slow vs a local disk. But if you have a large cluster of nodes requesting data at  the same time off of the same shared storage system, that storage starts looking very low latency. 
> - Mark
> 
> ----------------------------------------------------------------------
> 
> Message: 1will
> Date: Fri, 6 Feb 2015 00:41:25 +0000
> From: Peter Becker <pbecker at esri.com>
> To: "landsat-pds at lists.osgeo.org" <landsat-pds at lists.osgeo.org>
> Subject: [Landsat-pds] Tiling Scenes
> Message-ID: 
> 	<A6B8217F0F87DD47AD6ACF0E268DB249B94CCEC6 at RED-INF-EXMB-P1.esri.com>
> Content-Type: text/plain; charset="us-ascii"
> 
> I noticed that the scenes are currently compressed using Deflate and  a predictor of 2 (horizontal difference).
> The deflate brings down the file size, but does not allow sections of the imagery to be read without reading all previous pixels. This will significantly affect performance of any applications that only need to read parts of the image.
> I would like to recommend that the following is added to the GDAL_translate command
>     -co TILED=YES -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 Tiling will improve access and is a standard part of TIF.
> Using a tiling size of 512 is more optimum for storage that has higher latency.
> In my tests I noticed a slight (1-2%) decrease in the resulting filesize as well.
> 
> _Peter
> 
> -------------- next part -------------- An HTML attachment was 
> scrubbed...
> URL: 
> <http://lists.osgeo.org/pipermail/landsat-pds/attachments/20150206/baa
> 6bead/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 2
> Date: Fri, 6 Feb 2015 00:41:25 +0000
> From: Peter Becker <pbecker at esri.com>
> To: "landsat-pds at lists.osgeo.org" <landsat-pds at lists.osgeo.org>
> Subject: [Landsat-pds] Including Overviews
> Message-ID:
> 	<A6B8217F0F87DD47AD6ACF0E268DB249B94CCECC at RED-INF-EXMB-P1.esri.com>
> Content-Type: text/plain; charset="us-ascii"
> 
> Currently the scenes do not include any overviews. This forces applications to read the imagery at full resolution even if accessing at a small scale.
> It's common to include overviews/pyramids/reduced resolution datasets with such imagery.
> I would like to recommend that such overviews are included with the 
> imagery
> 
> Typically this would increase the file size by approx 33%, which is quite considerable.
> The size of the overviews can be reduced by skipping a level (eg use 
> level  4 8 16 32) vs 2 4 8 16 32, alternatively using a factor of 3 ie 
> 3 9 27 81 I tested this out on some images using Deflate with 
> predictor 2
> 2 4 8 16 32  adds about 35%
> 4 8 16 32  adds about 9%
> 3 9 27 81 adds about 13%
> My recommendation is to go with the 3 9 27 81 factors. This keeps the factor constant between all levels.
> Average sampling would be used, except for the BQA band for which Nearest (else Majority) should be used.
> 
> Implementation would only require adding GDALADDO to the existing 
> script
> 
> We would also need to determine if we use internal or external overviews.
> Internal overviews would increase the size of the files, but not change the directory structure.
> Using external overviews (.tif.ovr) would add additional files to the directory, is more specific to GDAL.
> 
> As I expect many users to be using GDAL to access these files, I would recommend that we use the external overviews. I don't see the additional files as a burden.
> 
> One other potential concern (and I'm hoping Frank can answer this) is the tile size of the overviews. GDAL appear to always use a tile size (BLOCKSIZE) of 128. It would be more optimum if the file size could be set to 512.
> 
> _Peter
> 
> -------------- next part -------------- An HTML attachment was 
> scrubbed...
> URL: 
> <http://lists.osgeo.org/pipermail/landsat-pds/attachments/20150206/5d1
> 223ae/attachment-0001.html>
> 
> ------------------------------
> 
> _______________________________________________
> Landsat-pds mailing list
> Landsat-pds at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/landsat-pds
> 
> 
> End of Landsat-pds Digest, Vol 2, Issue 4
> *****************************************
> _______________________________________________
> Landsat-pds mailing list
> Landsat-pds at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/landsat-pds
> 
> _______________________________________________
> Landsat-pds mailing list
> Landsat-pds at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/landsat-pds