#3454 closed defect (wontfix)
Poor performance of ECW->ECW window extraction , except when using no-op temporary warped VRT
| Reported by: | Even Rouault | Owned by: | warmerdam |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | GDAL_Raster | Version: | svn-trunk |
| Severity: | normal | Keywords: | ECW |
| Cc: |
Description
I've confirmed a report from a user on this forum (French) : http://georezo.net/forum/viewtopic.php?id=62434
How to reproduce :
0) Let's have a big ECW tile (from example a 21600x21600 x 3 band dataset converted from a BMNG tile) called src.ecw
1) Slow path : gdal_translate -of ECW src.ecw target.ecw -srcwin 0 0 512 512
--> takes 32 s on my PC
2) Fast path :
- gdalwarp -of VRT src.ecw src.vrt
- then, gdal_translate -of ECW src.vrt target.ecw -srcwin 0 0 512 512
--> takes 5.8s on my PC
Attached the output of the gdal_translate run with CPL_DEBUG in both cases.
Attachments (2)
Change History (5)
by , 14 years ago
by , 14 years ago
comment:1 by , 13 years ago
| Status: | new → assigned |
|---|
comment:2 by , 13 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | assigned → closed |
On reflection, I don't think it would be prudent to really try and address this situation within the ECW driver.
I'm going to close this ticket since I don't think action is warranted, though we might keep a possible rework of the VRT driver in the back of our mind to treat bands together.
comment:3 by , 13 years ago
Actually, I did a change recently in the VRT driver to help performance in the WMS driver with gdal_translate when using subwindow. The solution was to implement dataset RasterIO() in the very particular case where all VRT bands use an identical source dataset. I'm wondering if it wouldn't help for that ticket (but I haven't tested). The changeset was : http://trac.osgeo.org/gdal/changeset/21990/trunk/gdal/frmts/vrt
At core the problem here is that requests to the source file are getting issued as one scanline from band1, then one scanline from band 2, then one scanline from band 3, then second scanline from band 1...
This happens due to going through a VRT (from -srcwin) and the added aspect that the ECWCreateCopy is requesting data one line at a time. The problem is not the same - at least not so bad - when copying to a format that does things in chunks instead of single scanlines.
The ECW driver ends up setting a new window for each scanline for each band and setting windows is expensive.
It would help quite a bit if we could get the VRT driver to request all bands at ones but it is pretty inherent in it's architecture that it treats bands as distinct and unrelated so that would be hard. It would also help if we got the ECWCreateCopy method to request a bunch of scanlines at once instead of just one. That is pretty easy but will help only a relatively limited number of circumstances.
/me thinks...