Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: krpano.com Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

Mittwoch, 13. März 2019, 11:49

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*

2

Donnerstag, 14. März 2019, 18:32

Hi,

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,
Klaus