- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks!
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks!
An algorithm could look like thisand it isbasedon a geomatics related project I worked for:
1. There is a database with a list ofgeo-tiles,1024x1024 in total
2. Every geo-tile is 4096x4096 pixels ( 16-bits \4096x4096x2 bytes= 32MB )
3. Every geo-tile has to bedoubled in size( 16-bits \ 8192x8192x2 bytes = 128MB )
2. Allocate memory for 1024x1024 entries ( in-memory table of geo-tiles \ name is 8 bytes \ 8MB)
3. Read the list of geo-tilesfrom the database to the in-memory table of geo-tiles
4. Allocate 32MB buffer for a source geo-tile ( pSrcGeoTile )
5. Allocate128MB buffer for a destination geo-tile ( pDstGeoTile )
4. Start iterationsfor the in-memory table of geo-tiles
5. Load ageo-tile to pSrcGeoTile
6.Call ippiResize( pSrcGeoTile, pDstGeoTile, 2xWidth, 2xHight, INTERPOLATION )
7. Save the destination geo-tile from pDstGeoTile
8. Repeat 5, 6, 7 until end of the in-memory table of geo-tiles
9. Deallocate 128MB buffer
10. Deallocate 32MB buffer
11. Deallocate memory of in-memory table of geo-tiles
Best regards,
Sergey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My project currently uses OpenCV to do the same.OpenCV provides an interpolation mode "CV_INTER_AREA" which does not require boundary pixels when the ratio between source length and destination length are whole integers.
(As an example, resizing from 4096x4096 to 1024x1024 (downscale by 4 on each dimension), maps each patch of 16x16 source pixel into a 1x1 destination pixel. There is no visible seams (image artifacts) at the tile boundaries.)
We were testing IPP to see if there is any speed improvement. However, since IPP does not implement an equivalent interpolation mode, we have to use the CV_ANTIALIASING mode. Unfortunately this mode has huge memory requirement that we cannot affort.
Two of my main concerns are:
- Hoping to provide resize capability on arbitrary zoom ratios (not whole integers), with reasonable memory requirement.
- When the output tiles are put together, they must not have any unpleasant tile seams at the boundary. I can provide the boundary pixels, but the API must have a way to accept them in the first place.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
with current IPP API it is impossible to process a huge image by tiles as each call to Resize primitive will produce boundary artifacts. This inconvinience has been already fixed in the new Resize API version that will be available in the next major IPP release - it has "border" parameter that can be any of "replicate, mirror, const, etc." or "border is available in memory" - that makes possible to stich dst tiles correctly.
Regards,
Igor
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page