You are not logged in.

Dear visitor, welcome to Forum. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.


Wednesday, March 13th 2019, 11:49am

Tiling Efficiency for Big Flats

Just watching a large flat file tile out and thinking about it...
flat, size=142080x78366
which for me tiles out in 8 levels
level8 is written first, then l7,l6,l5...

level1 is only 6 tiles of 1152x636 which is tiny - it should take no time to write. But it takes a considerable amount of time (hence the thinking!). I'm guessing its reading the file from the original large size psb.
But it could get the same information from the tiles one level up level2 2176x1202 in 15 tiles. And my basic understanding of the kmaketiles command would lead me to believe that this would be massively quicker

This might only make sense to do on smaller level where there;s less than 1000 tiles. And I'm not sure how this would work with Equis
Just an idea *g*


Thursday, March 14th 2019, 6:32pm


But it could get the same information from the tiles one level up

No, that's not possible due the image-filtering. By default the Lanczos filter is used and that filter is not hierarchically split- or separable (sorry, not sure how to explain that correctly).

Using an already down-scaled level as new source would introduce aliasing artifacts, reduce details and can also cause sub-pixel-misalignment (you could see a slight shift during viewing when zooming-in and one level replaces the other one).

That means yes, each resolution level is generated from the large source image and that's done intentionally for quality reasons.

But I agree there are ways to speed that up and that's already on my todo-list.

Best regards,