AWARE [SYSTEMS] Imaging expertise voor de Delphi ontwikkelaar
AWare Systems, Imaging expertise voor de Delphi ontwikkelaar, Home TechTalks / Tiling versus banding
AWare Systems on-line

Home
Custom development
Imaging
TechTalks
    Bestandformaat uit gegevens
    Tiling versus banding
    VCL TGraphic grondbeginselen
    Ongebruikte kleur
Company
Links

Talen

  English version
  Nederlandse versie

Contact

Informatie: info@awaresystems.be
Helpdesk: support@awaresystems.be
Verkoop: sales@awaresystems.be



Valid HTML 4.01!



Tiling versus banding technieken voor het omgaan met grote beelden

> Waarom vindt u dat tiles (tegels) beter zijn dan bands (stroken)
> voor de verwerking van grote afbeeldingen?

Om verschillende redenen. De meeste daarvan komen neer op het feit is dat men, in de meeste situaties minder tile (tegel) geheugenblokken zal moeten lezen of schrijven dan band (strook) geheugenblokken. Hier zijn twee voorbeelden...

Wanneer u werkt op basis van een "tiling raster object" of een "banding raster object", zal zich vroeg of laat de behoefte doen gevoelen om toegang te krijgen tot een rechthoek in het raster. Laat ons ter wille van statistische validiteit aannemen dat die rechthoek een vierkant is en dat de afbeelding zeer groot is. Het feit dat de afbeelding zeer groot is, verandert de afmetingen van de tiles of tegels niet. Ze zijn bijvoorbeeld 1.000x1.000 pixels, of u nu te maken heeft met een totale rasterafmeting van 10.000x10.000 of van 100.000x100.000. Deze totale rasterafmetingen hebben echter wel een invloed om de afmetingen van bands of stroken. In het eerste geval, 10.000x10.000, zal een band die evenveel geheugen inneemt als de besproken tile een afmetingen hebben van 10.000x100 pixels; in het tweede geval zal de band 100.000x10 pixels groot zijn. Veronderstel nu dat u de rechthoek (0, 0, 2.000, 2.000) nodig heeft. Bij tiling hoeft u hiervoor slechts 4 tiles aan te spreken, zowel in het eerste als in het tweede geval. Bij banding moet u hiervoor 20 bands oproepen in het eerste geval en zelfs 200 bands in het tweede geval. Dat is uiteraard veel slechter en zal mogelijk aanleidnig geven tot een intensief gebruik van het wisselbestand of swapfile. Het is ook duidelijk dat het tiling scenario perfect schaalbaar is, terwijl in het banding scenario de zaken al snel uit de hand gaan lopen naarmate de afbeeldingen groter worden.

Hier een nog extremer voorbeeld. Stel dat u source tile array / band array moet roteren naar een doel tile array / band array, laat ons zeggen 90 graden. Stel dat u op een bepaald ogenblik heeft beslist om 'scanline streams' te gebruiken. (Ik zie immers geen andere haalbare manier om een beeldbewerkingsbibliotheek op basis van tile array of band array rasters te bouwen.) U zou kunnen roteren door 'scancolumns' van de source-array te nemen en deze als 'scanlines' in de doel-array te schrijven. Bij banding betekent toegang tot een kolom, toegang tot ALLE bands of stroken. Dat betekent dat u voor elke kolom in de afbeelding het volledige afbeeldingsgeheugen in en uit moet geswapt woren, en grote afbeeldingen tellen allicht een groot aantal kolommen... Bij de tiling techniek blijven de zaken veel beter beheersbaar, zelfs in dit voorbeeld, omdat u slechts een beperkt aantal tiles moet aanraken, of u nu toegang zoekt tot kolommen werkt of tot lijnen.

Een andere reden om de voorkeur te geven aan tiles is dat die opzet bestand is tegen zeer brede afbeeldingen met een grote bitdiepte, terwijl bij de banding-opzet in theorie de ingestelde geheugenlimiet per blok mogelijks niet volstaat om één enkele scanline op te slaan dan. Veronderstel dat u 64bit per kanaal vlottende komma CMYK met alfa opslaat. Dat zijn 40 bytes per pixel. Veronderstel verder dat de ingestelde geheugenlimiet per band gelijk is aan 200 kilobytes. (Ik ben het ermee eens dat deze limiet onpraktisch zou zijn, maar dit is dan ook een theoretisch argument tegen banding, geen praktisch.) Dat zou betekenen dat de maximale ondersteunde breedte van de afbeeldingen beperkt zou zijn tot 5.000 pixels, of dat u een uitzondering op de limiet zou moeten inlassen voor bands van één enkele lijn. Akkoord, dit is een erg theoretisch bezwaar, maar het zijn dit soort zaken die mij storen aan bands... Wie weet beslis je op een mooie dag om tot 255 maskerkanalen te ondersteunen of iets van die strekking. Ach, OK, toegegeven,... schrap deze laatste alinea maar. ;-)

Geef ons een seintje als u op de hoogte wilt blijven van de veranderingen of toevoegingen aan deze pagina.