FBO and image saving Errors under Raspberry Pi 2


I have a problem with my app.
I developed it under macOS (El Capitan) with oF0.9.8

Then i dowloaded the source code and built it under a Raspberry Pi 2 (under Raspbian PIXEL) model B using oF0.9.8

Everything is building and app is but i have errors which i don’t have under macOS


I also save image capture from a webcam into a JPG file

ofImage VideoPreview::grabCroppedFrame()
        ofImage img;
        img.allocate(camWidth, camHeight, OF_IMAGE_COLOR);
        if (cam.isInitialized()) {
            float cropHeight = camHeight;
            float cropWidth = (camWidth - (cropHeight * printRatio)) / 2;
            img = cam.getPixels();
            img.crop(cropWidth, 0, camWidth - cropWidth * 2, cropHeight);
        return img;

This is throwing me an error :

[ error ] ofImage: saveImage(): couldn't save "PRINT_163600.jpg", pixels are not allocated

Everything is running fine in macOS

I am aware openGL is quite different between macOS and RPi so i would say something is wrong there, but i can’t figure it out. What would you the problem could be ?

thanks a lot

where are you calling grabCroppedFrame (e.g. in update() or draw())?

thank you for your answer.

i call it in ofApp in a listener function which is triggered hen a timer is out

void ofApp::onTimerEnd(const bool &val) {
    ofImage img;
    img = preview.grabCroppedFrame();
    compose.add(img, word.pickedText);

Not sure what’s going on but i would change the following things anyway to make things faster, might even fix it as well :slight_smile:

  • you are clearing the image right after allocating it so the allocation doesn’t have any effect and will slow down things:

  • i would also store the image as an instance variable in your class so you don’t have to allocate it every frame which can be really slow in the RPI

  • and also add a second image so you can crop with allocating too

  • by passing the pixels to an image it’ll also upload them unnecessarily to a texture if you only want to save them (if you want to preview them you can then later use an ofTexture and loadData)

ofPixels img;

ofPixels & VideoPreview::grabCroppedFrame(){
    if (cam.isInitialized()) {
        float cropHeight = camHeight;
        float cropWidth = (camWidth - (cropHeight * printRatio)) / 2;
        cam.getPixels().cropTo(img, cropWidth, 0, camWidth - cropWidth * 2, cropHeight);
    return img;


ofSaveImage(videoPreview.grabCroppedFrame(), "image.jpg");


Thanks a lot for your answer.
I applied all your suggestions for the purpose of optimization, but no luck so far.

Everything is still fine in macOS but not in Raspberry

i tried in a virtual machine under Debian 8.7 and there is no problem at all

must be something dealing with the raspberry architecture

I would try setting a flag in onTimerEnd and doing the processing inside of update or draw

void ofApp::onTimerEnd(const bool &val)
    doSaveImage = true;
void ofApp::update()
        //arturo's implementation
        doSaveImage = false;


thanks for the advice.
i changed as suggested, but nothing new…

here are some more code if it could be of any help…

void Composer::create() {

    comp.allocate(printWidth, printHeight, GL_RGB);
    bat.allocate(printWidth, printHeight, GL_RGB);
    ofImage img;
    ofSetColor(255, 255);
    img.draw(printWidth, 0, -printWidth, printHeight);

then i save the image

void Composer::save()
    string timeFormat = "%H%M%S";
    string timeStamp = ofGetTimestampString(timeFormat);
    ofSaveImage(bat, labels.at(0) + "_PRINT_" + timeStamp + ".jpg");

i figured every fbo allocation threw me an error every time i was allocating one

allocating flash fbo
allocating bat fbo
allocating pol fbo

everything ran fine under macOS and Linux (Debian 8.7) so it was something definitely dealing with the Raspberry Pi and obviously was the source of the saving image issue i had.

I had already done it earlier but upgrading the raspberry pi firmware seems to have all the custom settings reset to defaults. So i set GPU memory split back to 128M instead of 64M and everything is running fine now !

thanks for your help.