subsampling grote dataset

[jaapstobbe]

Hallo,

Ik heb een dataset van 14 gig, die bestata uit partcile posities in 3D. Nu wil ik deze file graag subsampelen door steeds in elke dimensie een particle om en om over te slaan. Dus word de file 2x2x2 = 8 keer kleiner (zal dus ongeveer 1.8gig worden), en dan kan ik er wel mee werken.

Weet iemand van jullie een programma waarmee ik dat makkelijk kan doen? Ik wil de file dus subsamplen, aangeven dat ie steeds een aantal shorts moet overslaan en wegschrijven naar een nieuwe file. Als er een C++ library voor is kan ik dat ook gebruiken.

[ Voor 9% gewijzigd door jaapstobbe op 01-11-2006 17:15 ]

[RobIII]

Ik vrees dat je dat zelf aan het schrijven komt; lijkt me niet iets wat in een of andere library kant-en-klaar zit; zeker niet als je niet aangeeft hoe die file in elkaar steekt of welk formaat 't is.

Maar zoveel moeite is het toch niet om dat zelf te schrijven, of...

[jaapstobbe]

RobIII schreef op woensdag 01 november 2006 @ 17:33:
Ik vrees dat je dat zelf aan het schrijven komt; lijkt me niet iets wat in een of andere library kant-en-klaar zit; zeker niet als je niet aangeeft hoe die file in elkaar steekt of welk formaat 't is.

Maar zoveel moeite is het toch niet om dat zelf te schrijven, of...

ike heb ook wel code die binary files kan inlezen en wegschrijven, maar files groter dan 1.5 gig kan ie niet aan...ik wil dus graag iets dat dat wel kan

[RobIII]

jaapstobbe schreef op woensdag 01 november 2006 @ 17:48:
[...]


ike heb ook wel code die binary files kan inlezen en wegschrijven, maar files groter dan 1.5 gig kan ie niet aan...ik wil dus graag iets dat dat wel kan

Ik vermoed eerder dat de grens bij 2.1Gb ligt (2^31-1 grens)...

[jaapstobbe]

RobIII schreef op woensdag 01 november 2006 @ 17:50:
[...]

Ik vermoed eerder dat de grens bij 2.1Gb ligt (2^31-1 grens)...

ja, dat kan ook....iig, plz help

[RobIII]

jaapstobbe schreef op woensdag 01 november 2006 @ 17:53:
[...]


ja, dat kan ook....iig, plz help

Ja best... en wat wil je dan dat we doen? Googlen kun je zelf, geef dan maar eens aan wat je gevonden en geprobeerd hebt en wat daar niet aan werkt; je topic is nogal vaag (ik mis een programmeertaal o.a.) en hier kunnen we weinig mee. Check ook even de Programming Beleid Quickstart.

Hier in [PRG] gaat het over zélf programmeren. Als je kant-en-klare software zoekt zit je in [PRG] aan het verkeerde adres

[ Voor 18% gewijzigd door RobIII op 01-11-2006 18:07 ]

[jaapstobbe]

RobIII schreef op woensdag 01 november 2006 @ 17:55:
[...]

Ja best... en wat wil je dan dat we doen? Googlen kun je zelf, geef dan maar eens aan wat je gevonden en geprobeerd hebt en wat daar niet aan werkt; je topic is nogal vaag (ik mis een programmeertaal o.a.) en hier kunnen we weinig mee. Check ook even de Programming Beleid Quickstart.

Hier in [PRG] gaat het over zélf programmeren. Als je kant-en-klare software zoekt zit je in [PRG] aan het verkeerde adres

Ik heb gegoogled en hier gezocht maar kan helaas niets vinden.
Ik zoek een tool of een stukje code waarmee ik dus zeer grote files(14 gig) kan inlezen en deze "stream aan data" dus kan filteren en wegschrijven naar een andere binaire file. Winrar kan ook grote files openen en extracten dus hardware gebonden ben ik blijkbaar niet...Maar een simpele c++ lib zoals <iostream> kan zulke grote files niet handlen, is er iets anders voor handen?

[Creepy]

Tuurlijk kan je zulke grote files wel handlen, je moet alleen niet de gehele file in 1 keer willen inlezen maar blok voor blok.

[Soultaker]

jaapstobbe schreef op woensdag 01 november 2006 @ 17:14:
Ik heb een dataset van 14 gig, die bestata uit partcile posities in 3D. Nu wil ik deze file graag subsampelen door steeds in elke dimensie een particle om en om over te slaan.

Erm, hoe stel je je dit voor? Zijn die particles geordend in een drie-dimensionaal grid ofzoiets? Als het gewoon een heleboel 3d posities zijn zie ik niet in hoe je kiest wat je overslaat.

Als ze in een grid zitten, is het (conceptueel) een kwestie van één voor één inlezen en beslissen of je die gegevens wil behouden, en zo ja, wegschrijven.

[alx]

Gewoon, zeg, iedere sample met even indices eruit nemen en opslaan is vrij eenvoudig. Enkele tientallen regels C of whatever kunnen dat al. Filter tijd hangt van hd perf af. Maar samples weggooien is niet altijd acceptabel.

Beter is het om een filtering kernel te gebruiken; een soort wegingsmasker die een sample neemt door enkele samples in de buurt van het samplepunt te combineren. Dan kun je alleen niet meer buffertje voor buffertje lineair inlezen, want je hebt ook waarden uit vorige en volgende kolommen, etc nodig.
Ik zou dan 3d blokken inlezen per keer (grootte afhankelijk van geheugen cap), die filteren en de resulterende blokken "aan elkaar plakken" (hersorteren dus). Dat kan een tijdje duren maar dat hoeft geen probleem te zijn als het maar 1x of een paar keer moet.

Maar ben je van plan zelf wat te proggen of hoop je iets te "vinden"?

[jaapstobbe]

Dit is de simpele code die ik altijd gebruikte om grote files ~600MB in te lezen, maar veel groter is dus een probleem en ik snap niet waarom..of moet ik bijvoorbeeld meerder kleinere memblocken gebruiken?:

code:

    ifstream::pos_type size;
    ifstream file(filename, ios::in|ios::binary|ios::ate);
    if (file.is_open())
    {
        size = file.tellg();
        memblock = new char [size];
        file.seekg (0, ios::beg);
        cout << "Loading data...";
        file.read (memblock, size);
        file.close();
        cout << "the complete file content is in memory: " << size << " Bytes." <<endl;
    }
    else cout << "unable to open file";

Ik heb 1 Gig intern geheugen, maar ik neem aan dat windows toch zelf wel het mem kan handelen, swappen enzo?

Soultaker schreef op woensdag 01 november 2006 @ 21:11:
[...]

Erm, hoe stel je je dit voor? Zijn die particles geordend in een drie-dimensionaal grid ofzoiets? Als het gewoon een heleboel 3d posities zijn zie ik niet in hoe je kiest wat je overslaat.

Als ze in een grid zitten, is het (conceptueel) een kwestie van één voor één inlezen en beslissen of je die gegevens wil behouden, en zo ja, wegschrijven.

Niet zo moeilijk hoor... die file is gewoon een 3D array, positie in de file(1D array) is positie in het grid, en de waarde is de waarde die ik een mooi kleurtje ga geven.

[ Voor 34% gewijzigd door jaapstobbe op 01-11-2006 21:41 ]

[Soultaker]

In 32-bits Windows kun je normaal maar <2GB in userspace mappen (of <3GB met een tweak). Daar gaat swappen niet bij helpen. Sowieso is voor dit soort grote bestanden memory mapping de way to go, als het echt niet mogelijk is om het bestand stukje bij beetje te verwerken (wat je nog steeds niet aannemelijk hebt gemaakt).

Geef eerst eens concreet aan wat je probeert te doen.

[Verwijderd]

Ik denk dat je de windows API hiervoor moet gebruiken om dit te doen, op google is hier genoeg over te vinden.

edit: laat mij het refraseren, ik neem aan dat je het in blokken kunt lezen de stream. Lijkt mij ook logisch. Ik bedoel eigenlijk dat je met de API van windows voor het schrijven en lezen van bestanden veel meer kunt, dus ik zou het daar maar eens mee proberen.

[ Voor 54% gewijzigd door Verwijderd op 01-11-2006 21:45 ]

[Verwijderd]

Ter inspiratie kun je misschien ook even deze thread bekijken:

[Java] Zo efficient mogelijk speciale karakters filteren

Het gaat daar weliswaar om Java, maar de concepten van het streamen van data door je code heen zijn identiek. In het geval van die thread kon de beslissing wat te doen per byte genomen worden. Als dat bij jou niet kan, dan lees je gewoon wat meer in (per block dus). Enkele oplossingen daar doen dat sowieso al.

Alleen als je beslissing mogelijk over de grens van een block heen valt moet je wat extra coden, maar als je een beetje abstract kunt denken dat is dat zeker wel te doen.

[MisterData]

Als het echt gaat over een gigantisch binair bestand met daarin plaatsgegevens van particles in een 3D-space doe je er misschien goed aan om dat hele ding eerst te converteren naar bijvoorbeeld een Octree. Daarmee deel je je 3D-ruimte als het ware in vakken op, zodat je makkelijker particles bij elkaar kunt zoeken. Octrees worden ook gebruikt in 3D-spellen voor bijvoorbeeld collision detection en dergelijke. Voordeel is dat je niet altijd de hele tree in het geheugen hoeft te hebben, maar alleen het stukje van de octree waar de te verwerken particle in ligt. Heeft die particle dan informatie nodig uit andere 'takken' van de octree, dan kun je die on-demand laden. Afhankelijk van het algoritme dat je voor ogen hebt denk ik dat je in de meeste gevallen genoeg hebt aan particles die 'in de buurt zijn' van de huidige particle