Live view processing performance.

[smallfly]

Hi,

How could we make this faster? The ofLoadImage() call is the one demanding the most part of the processing time. Would ofxCV be of help for this?

lock();
if(liveBufferMiddle.size() > 0) {
    // decoding the jpeg in the main thread allows the capture thread to run in a tighter loop.
    ofBuffer* middleFront = liveBufferMiddle.front();
    liveBufferFront.set(middleFront->getBinaryBuffer(), middleFront->size());
    liveBufferMiddle.pop();
    unlock();
    ofLoadImage(livePixels, liveBufferFront);
        livePixels.rotate90(rotateMode90);
    if(liveTexture.getWidth() != livePixels.getWidth() ||
        liveTexture.getHeight() != livePixels.getHeight()) {
        liveTexture.allocate(livePixels.getWidth(), livePixels.getHeight(), GL_RGB8);
    }
    liveTexture.loadData(livePixels);
    lock();
    liveDataReady = true;
    frameNew = true;
    unlock();
} else {
    unlock();
}

Thanks

[kylemcdonald]

ofLoadImage() is actually taking a compressed jpg, decompressing it, and loading it into pixels. that's going to be an intensive operation no matter what. i think OF is using libjpeg via FreeImage for this, you could try wrapping your own decoder like libjpeg-turbo or there might be a faster native solution for your platform, or there might be a library that decodes on the GPU.

it would be good to double-check that the livePixels are not being reallocated by ofLoadImage(). that would be a performance hit.

[smallfly]

Yep exactly... decompressing and loading into pixels is heavy. Thanks for the link to libjpeg-turbo though. Using ofxTurboJpeg I have been able to test this in minutes, and the perf are already better.

[kylemcdonald]

great! going to close this issue. please report the exact performance difference if you get a chance.

[smallfly]

For sure, I will post here some more details when I will have that running in a simple example project in order to really see the difference.