[C++]Array van beelden -> memory en daarna -> schijf

[zandpaddo]

Wij zitten met een probleem. Voor een project voor mijn studie zijn wij bezig om beelden uit een firewire camera te halen. Bij deze camera zit een SDK met c++ files. Tussen deze files zit een pre-programmed viewer die de beelden uit de camera haalt en op het scherm laat zien.

Wij hadden deze viewer dusdanig aangepast dat deze het beeld niet meer weergeeft maar een serie beelden als .tif op schijf opslaat. Nu is het alleen zo dat zodra de programmatuur bezig gaat met het wegschrijven van de serie beelden de harde schijf de bottleneck is. Hierdoor kunnen we niet realtime alle beelden opslaan.

Nu hadden we bedacht om de beelden eerst naar het geheugen weg te schrijven (bufferen) en daarna ze een voor een op schijf te zetten. Het geheugen zou hier snel genoeg voor moeten wezen. Dit krijgen wij echter niet voor elkaar. Het is volgens mij niet zo heel ingewikkeld, maar het nadeel is dat we redelijke c/c++ noobs zijn. Dus wie kan ons helpen.

De relevante code (direct uit SDK):

code:

void CMainFrame::callbackNewFrame(void* context, PdtFrame* pFrame)
{
    CMainFrame*         pThis = (CMainFrame*) context;


    // 1. Update view.

    pThis->m_wndView.CopyFrame(pFrame);

    // 2. Update histogram, if it's open.

    pThis->m_lockHistogramWnd.Lock();

    if (pThis->m_pWndHistogram)  //ZZZZ Known bug...
        pThis->m_pWndHistogram->UpdateHistogram(pFrame);

    // 3. Save this to a file?
    if (!pThis->m_saveFrame.IsEmpty())
    {
        ImageWriteTiff(pThis->m_saveFrame, pFrame);
        pThis->m_saveFrame.Empty();
    }

    pThis->m_lockHistogramWnd.Unlock();
}

Zodra er een nieuw frame is wordt deze functie aangeroepen, wordt het beeld ververst en indien een user ervoor kiest om het beeld op te slaan wordt deze opgeslagen.

Het adres van de betreffende frame staat in een pointer Pframe welke van het type PdtFrame is.

Kan iemand ons miss helpen met een paar regels code wat het geheugen alloceert, betreffende frame naar een array schrijft en dmv ImageWriteTiff na de serie beelden weggeschreven wordt.

[Maxxi]

Gebruik:

malloc (http://en.wikipedia.org/wiki/Malloc)

Icm sizeof pThis en stop deze pointer in een array.

Klaar?

Edit: maak gewoon elke keer een nieuwe pointer aan (en "free" de oude niet!!), en dan in array.

[ Voor 30% gewijzigd door Maxxi op 10-04-2007 20:40 ]

[MSalters]

Nee, dat werkt ook niet. Ik zou toch adviseren om iets meer kennis in huis te halen. Misschien op een lokale hogeschool/universiteit een student vinden die voor 20 euro per uur bij wil klussen? Wat je wil is namelijk niet in die ene functie te doen.

[Maxxi]

MSalters schreef op dinsdag 10 april 2007 @ 20:47:
Nee, dat werkt ook niet. Ik zou toch adviseren om iets meer kennis in huis te halen. Misschien op een lokale hogeschool/universiteit een student vinden die voor 20 euro per uur bij wil klussen? Wat je wil is namelijk niet in die ene functie te doen.

Waarom zou dat niet werken?

Je hebt alleen een 2e methode nodig voor het opslaan op disk.

[ymoona]

Je kan het maken met een list van beelden, desnoods met twee treads, maar dan moet je wel even uitzoeken hoe het zit met twee gebruikers in een list.

[zandpaddo]

Hmm het is dus niet erg eenvoudig?

Malloc hadden we idd al geprobeerd maar dat ging niet goed (geheugengebruik bleef hetzelfde).

Wij dachten eerst gewoon simpelweg de data dmv de pointer in een array op te slaan en dat later uit te lezen. Maar dat lukte dus niet .

Overigens is bovenstaande functie een onderdeel van een groter programma met diverse subfiles en functies

[GX]

Schrijf je dan niet langzaamaan je hele geheugen vol? Dan ben je nog nergens.

[Maxxi]

Malloc hadden we idd al geprobeerd maar dat ging niet goed (geheugengebruik bleef hetzelfde).


Ehmm, het ging toch met het schijf gebruik?
Post je code es.

En je slaat het toch pas op na een tijd gebuffert te hebben?

[zandpaddo]

GX schreef op dinsdag 10 april 2007 @ 21:16:
Schrijf je dan niet langzaamaan je hele geheugen vol? Dan ben je nog nergens.

Dat maakt niet zoveel uit. Het programma hoeft niet netjes geprogrammeerd te zijn. Het moet 1 reeks van beelden (zeg een paar 100 stuks op 640*480) naar het geheugen weg kunnen schrijven en deze later op kunnen slaan. Als het maar ff 1x werkt is het goed, als je daarna moet rebooten is niet zo erg.

Maxxi schreef op dinsdag 10 april 2007 @ 21:20:

Malloc hadden we idd al geprobeerd maar dat ging niet goed (geheugengebruik bleef hetzelfde).


Ehmm, het ging toch met het schijf gebruik?
Post je code es.

En je slaat het toch pas op na een tijd gebuffert te hebben?

Ja, malloc hadden we later geprobeerd nadat het direct opslaan van de 1ste serie beelden was gelukt. Code komt eraan, moet ff doorgemaild worden door mn projectgenoot.

[ Voor 43% gewijzigd door zandpaddo op 10-04-2007 21:25 ]

[Arjan]

Ik snap er niks van, je krijg de data toch gewoon binnen?
wat is er mis met een vector van pointers naar PdtFrame's?
Als deze pointer steeds naar dezelfde plek wijst gebruik je toch gewoon de copy-constructor?

lijkt mij vrij simpel, maar misschien begrijp ik het probleem niet.
Geheugengebruik is natuurlijk wel een issue, maar ( ( 100 * 640 * 480 * 3 ) / 1024 ) / 1024 = 90Mb is voor een moderne computer natuurlijk peanuts.

[edit]
voor de duidelijkheid een voorbeeld waarbij ik de binnenkomende frames kopieer.

code:

static std::vector<PdtFrame> storedFrames;
static std::vector<CMainFrame> storedContext;

void CMainFrame::callbackNewFrame(void* context, PdtFrame* pFrame) {

    storedFrames.push_back(*pFrame);

    storedContext.push_back(*context);
}

void slaDieShitOp() {

    for(int i=0; i<storedFrames.size() && i <storedContext; i++) {
        ImageWriteTiff( storedContext[i].m_saveFrame, storedFrames[i]);
    }
}

liever gebruik je een map voor dit soort dingen.

[ Voor 40% gewijzigd door Arjan op 10-04-2007 21:39 ]

[zandpaddo]

Het is een beetje een zooitje, maar onze niet werkende code van het proberen te alloceren van geheugen.

code:

void CMainFrame::callbackNewFrame(void* context, PdtFrame* pFrame)
{
    CMainFrame*         pThis = (CMainFrame*) context;
  static int i= 0;
  int k=0;
  PdtFrame* plaatje;
  PdtFrame* plaatjes;
  
  char name[256];
    // 1. Update view.

    // pThis->m_wndView.CopyFrame(pFrame);

    // 2. Update histogram, if it's open.

    /* pThis->m_lockHistogramWnd.Lock();

    if (pThis->m_pWndHistogram)  //ZZZZ Known bug...
        pThis->m_pWndHistogram->UpdateHistogram(pFrame); */

    sprintf(name,"%d.tif", i++);
    if (i == 0 ) plaatjes = (PdtFrame*) calloc(100, sizeof(*pFrame));
    // printf("formaat=%d", sizeof(pFrame));
    if (i<100) {
        memcpy(plaatjes[i],*pFrame,sizeof(*pFrame));
    }
    if (i > 99 && i <200){
                ImageWriteTiff(name,plaatjes[k]);
                k++;
    }



    // 3. Save this to a file?
    if (!pThis->m_saveFrame.IsEmpty())
    {
        ImageWriteTiff(pThis->m_saveFrame, pFrame);
        pThis->m_saveFrame.Empty();
    }

    pThis->m_lockHistogramWnd.Unlock();
    
}

[Arjan]

het is inderdaad een rommeltje, maar wat ik zo wel kan zeggen zonder het proberen te lezen, is dat je in een callback functie zit. Als je elk frame plek gaat maken voor nog 100 frames dan ga je wel een klein beetje een probleem krijgen met geheugen ja...

[Maxxi]

code:

private * Plaatjes<CMainFrame> [100];
    private int i = 0;

void CMainFrame::callbackNewFrame(void* context, PdtFrame* pFrame)
{
    CMainFrame*            pThis = (CMainFrame*) context;


    // 1. Update view.

    pThis->m_wndView.CopyFrame(pFrame);

    // 2. Update histogram, if it's open.

    pThis->m_lockHistogramWnd.Lock();

    if (pThis->m_pWndHistogram)  //ZZZZ Known bug...
        pThis->m_pWndHistogram->UpdateHistogram(pFrame);

    // 3. Save this to a file?

    Plaatjes[i] = &pThis; // Douw plaatje in array
    i++; // Tel aantal plaatjes 1tje op
    
    if(i >= 100){ // Als 100 plaatjes, save to disk
    for(int y = 0; y <= 100; y++){
        
        if (!Plaatjes[y]->m_saveFrame.IsEmpty())
        {
            ImageWriteTiff(Plaatjes[y]->m_saveFrame, pFrame);
            Plaatjes[y]->m_saveFrame.Empty();
        }

        Plaatjes[y]->m_lockHistogramWnd.Unlock(); // Wat doet dit?
    }
}

Is niet gecompiled, misschien syntax error ofzo, maar volgens mij moet dit priciepe gewoon werken.

[ Voor 6% gewijzigd door Maxxi op 10-04-2007 21:47 ]

[zandpaddo]

thanks, morgen gaan we het proberen (heb nu de camera niet bij de hand, ligt op uni).

[Maxxi]

zandpaddo schreef op dinsdag 10 april 2007 @ 21:48:
thanks, morgen gaan we het proberen (heb nu de camera niet bij de hand, ligt op uni).

no offence, maar op universiteit en je komt hier zelf niet uit?

Ik @ HBO Technische informatica 2e jaar met 6 weken C/C++.


Btw, zet de int i weer terug op 0 nadat files opgeslagen zijn.
En check pointers goed, of het juist wel of juist niet met een & ervoor moet.

Succes

[zandpaddo]

Maxxi schreef op dinsdag 10 april 2007 @ 21:59:
[...]


no offence, maar op universiteit en je komt hier zelf niet uit?

Ik @ HBO Technische informatica 2e jaar met 6 weken C/C++.


Btw, zet de int i weer terug op 0 nadat files opgeslagen zijn.
En check pointers goed, of het juist wel of juist niet met een & ervoor moet.

Succes

Die Histogram is een extra functie die een histogram van het plaatje laat zien. Niet relevant voor het verkrijgen en opslaan van beelden

Jep, i know, maar ik ben geen informatica student. Ben werktuigbouwkunde student en wij hebben nooit C/C++ geleerd. Heb van het weekend de basis voor c doorgenomen en ben al blij dat ik eenvoudige code kan lezen.

[ Voor 10% gewijzigd door zandpaddo op 10-04-2007 22:03 ]

[DroogKloot]

Om de 100 frames een geheugendump maken zal ook niet fijn werken, dat betekent namelijk nog steeds dat je elke ~5 seconden (even aannemende dat de framerate van dat ding 20 is) een mega-vertraging krijgt in plaats van per frame een kleine als de schrijf-operaties niet asynchroon verlopen. Je zult je moeten verdiepen in threads, als je tenminste echt realtime (en langer dan een paar seconden ) bezig wilt zijn.

[MSalters]

Helaas van je weekend, dit is geen C, maar C++. memcpy gaat dus waarschijnlijk niet werken. Een nieuwe kopie maken van PdtFrame* pFrame doe je zo:

C++:

std::list<PdtFrame*> theFrames;
void CMainFrame::callbackNewFrame(void* context, PdtFrame* pFrame)
{
  PdtFrame* copy = new PdtFrame(*pFrame); // make a copy
  theFrames.push_back(copy); // store it.
}

De list opruimen doe je zo

C++:

while (!theFrames.empty()) { // zolang we er nog hebben
  delete theFrames.front(); // Gooi er een weg, omgekeerde van new
  theFrames.pop_front(); // en naar de volgende
}

Met een beetje geluk kan het iets simpeler, maar minder efficient

C++:

std::list<PdtFrame> theFrames; // Geen pointers hier
void CMainFrame::callbackNewFrame(void* context, PdtFrame* pFrame)
{
  theFrames.push_back(*pFrame); // Store a copy in theFrames
}

[ Voor 19% gewijzigd door MSalters op 11-04-2007 20:43 ]

[MSalters]

DroogKloot schreef op dinsdag 10 april 2007 @ 23:04:
Om de 100 frames een geheugendump maken zal ook niet fijn werken... Je zult je moeten verdiepen in threads, als je tenminste echt realtime bezig wilt zijn.

Nee hoor, overlappen I/O werkt ook uitstekend, en dan heb je geen threads nodig.

[zandpaddo]

MSalters schreef op woensdag 11 april 2007 @ 20:41:
Helaas van je weekend, dit is geen C, maar C++. memcpy gaat dus waarschijnlijk niet werken. Een nieuwe kopie maken van PdtFrame* pFrame doe je zo:

C++:

std::list<PdtFrame*> theFrames;
void CMainFrame::callbackNewFrame(void* context, PdtFrame* pFrame)
{
  PdtFrame* copy = new PdtFrame(*pFrame); // make a copy
  theFrames.push_back(copy); // store it.
}

De list opruimen doe je zo

C++:

while (!theFrames.empty()) { // zolang we er nog hebben
  delete theFrames.front(); // Gooi er een weg, omgekeerde van new
  theFrames.pop_front(); // en naar de volgende
}

Met een beetje geluk kan het iets simpeler, maar minder efficient

C++:

std::list<PdtFrame> theFrames; // Geen pointers hier
void CMainFrame::callbackNewFrame(void* context, PdtFrame* pFrame)
{
  theFrames.push_back(*pFrame); // Store a copy in theFrames
}

Okeej, gaan we ook even proberen. Hoe haal ik een voor een de pointer van de opgeslagen frames uit "theFrames" voor het wegschrijven naar tif?

De code van Maxxi werkte iig niet. Het ging fout met de private declaraties. Gaf een error dat er een ; voor moest. Tig dingen geprobeerd maar werkte niet.

Het probleem zit m er voornamelijk in dat die functie "void CMainFrame::callbackNewFrame(void* context, PdtFrame* pFrame)" iedere keer opnieuw aangeroepen wordt na een nieuw frame en de voorgaande daardoor frames gewist worden. Er moet dus iets gecreerd worden waarin 1 voor 1 de frames worden opgeslagen met bijbehorende pointers en dat deze ook nog behouden blijft bij een volgend frame.

C++ is inderdaad een stuk ingewikkelder voor de buitenstaander dan C. Al zitten er ook wel overeenkomsten tussen. Maar als het niet lukt laten we het maar zo, kunnen hier niet te lang bij stilstaan. Dan voorlopig maar een reeks beelden die niet 100% een vaste tijdsinterval hebben.

_{overigens komen alle files uit een SDK van Prosilica (de fabrikant). Zie http://www.prosilica.com/products/1394_sdk.html}

[Arjan]

zandpaddo schreef op woensdag 11 april 2007 @ 21:10:
[...]

Het eerste stukje code wat ik gister gepost heb doet echt exact wat je wil, je moet alleen zelf kiezen wanneer je genoeg frames hebt en wanneer je gaat wegschrijven...

MSalters schreef op woensdag 11 april 2007 @ 20:41:
[...]

Met een beetje geluk kan het iets simpeler, maar minder efficient

C++:

std::list<PdtFrame> theFrames; // Geen pointers hier
void CMainFrame::callbackNewFrame(void* context, PdtFrame* pFrame)
{
  theFrames.push_back(*pFrame); // Store a copy in theFrames
}

Waarom zou dat minder efficiënt zijn?
Voor een dergelijke bewerking wordt gewoon de copy-operator aangeroepen.

[ Voor 47% gewijzigd door Arjan op 11-04-2007 21:57 ]

[.oisyn]

De copy-constructor kan potentieel heel erg duur zijn omdat er buffers gealloceerd en gekopieerd moeten worden. De r-value reference is er helaas nog niet

[ Voor 3% gewijzigd door .oisyn op 12-04-2007 01:41 ]

[MSalters]

Ja, maar dat is geen verschil. De new uit m'n eerste voorbeeld gebruikt ook de copy ctor. De efficiency is meer gelegen in je memory allocaties, maar daarom is het maar een klein verschil.

[.oisyn]

De new uit je eerste voorbeeld gebruikt 1 (PdtFrame) copy ctor, terwijl je tweede voorbeeld er theFrames.size() gebruikt als theFrames.size() == theFrames.capacity() (en er dus een nieuwe buffer gealloceerd moet worden omdat dat extra element er niet bij past)

[MSalters]

vector != list

[Arjan]

MSalters schreef op donderdag 12 april 2007 @ 23:13:
vector != list

true, maar voor kleine collecties had ik begrepen dat een vector efficiënter was.

maar zoals ik al zei, omdat je 2 items gelinkt met elkaar wil opslaan, is een map wellicht handiger.

[.oisyn]

MSalters schreef op donderdag 12 april 2007 @ 23:13:
vector != list

Ai, daar ging het mis . Dan heb ik niets gezegd.

[Verwijderd]

Ik vraag me toch af waarom die school niet gewoon een camera kan uitlenen waar gewoon een behoorlijk videoprogramma bijzit om realtime op te nemen maargoed. Is dit soms een highspeed camera voor een speciaal experiment ofzo?

Ik kan wel een goede tip geven: de DirectX-SDK levert diverse goede kant en klare tools voor dit soort dingen. Je haalt gewoon de libs en headers van DX9 binnen in dat stuk code. Daarna werk je een voorbeeldje uit van MSDN bv.: http://msdn2.microsoft.com/en-us/library/ms779895.aspx

[Arjan]

Verwijderd schreef op vrijdag 13 april 2007 @ 02:27:
Ik vraag me toch af waarom die school niet gewoon een camera kan uitlenen waar gewoon een behoorlijk videoprogramma bijzit om realtime op te nemen maargoed. Is dit soms een highspeed camera voor een speciaal experiment ofzo?

Ik kan wel een goede tip geven: de DirectX-SDK levert diverse goede kant en klare tools voor dit soort dingen. Je haalt gewoon de libs en headers van DX9 binnen in dat stuk code. Daarna werk je een voorbeeldje uit van MSDN bv.: http://msdn2.microsoft.com/en-us/library/ms779895.aspx

Eerlijk gezegd vind ik DirectShow een regelrechte aanfluiting. Het filter dat je nodig zou hebben voor de frames uit een graph te halen, de SampleGrabber accepteerd maar enkele zeer specifieke inputformaten. Daarnaast gooit de standaard dvgrabber van DirectShow de beeldlijnen om, alsof het ntsc signaal is dat uit de camera komt. Dit heb ik alleen kunnen oplossen door de laatste alpha release van ffdshow te installeren en de DV-decoder daaruit te forceren. Zonder dit ziet het beeld eruit alsof het maar een kwart van de beeldlijnen heeft, tenzij je zelf een filter schrijft die de beeldlijnen weer omgooit...

Daarnaast vind ik het programmeren volgens de DirectShow manier met het ophalen van allerlei interfaces en filters aanroepen aan de hand van GUIID's enzo verschrikkelijk, maar dat is wellicht een persoonlijke frustratie.

[0rbit]

Om het nog verder te optimaliseren: Kun je die cam niet in RAW mode (of in een ander pseudo-native format) uitlezen? Of op zijn minst run length coding aanzetten? Dat gaat over het algemeen sneller dan eerst naar sRGB omzetten en dan opslaan.

[zandpaddo]

Verwijderd schreef op vrijdag 13 april 2007 @ 02:27:
Ik vraag me toch af waarom die school niet gewoon een camera kan uitlenen waar gewoon een behoorlijk videoprogramma bijzit om realtime op te nemen maargoed. Is dit soms een highspeed camera voor een speciaal experiment ofzo?

Je slaat de spijker op de kop . Er is wel software voor maar die kostte 2500 euro per licentie en was ook nog eens enorm brak. Helaas is de leen-camera nu sinds vandaag weer weg. Het is niet gelukt om een goede sequence van beelden te capturen, ondanks jullie goede tips.