Vector of image file ordering problem in Pi2

Hi,

I’m new to oF (and loving it). I’ve written a very basic app that loads a vector of bitmap image files and animates them in relation to sound playback speed, which is determined by a mechanical crank.

Things work perfectly on PC/Mac.

HOWEVER…

I’ve just setup a Raspberry Pi 2 Model B (and yes, I did all the updates, codecs, dependencies, etc).

I’ve tested on several displays – Sony TV via HDMI, PiTFT, and the one I’ll be using for various projects, and am currently running, a 5" 800x480 HDMI with touch.

In general the oF examples all run fine, EXCEPT the graphics/imageSequence, which for some reason plays back the individual frames totally out of order. The identical thing is happening in my app. So…

I reduced things to the bare bones, and am doing nothing but reading in a vector of images, using the code from the imageSequence example. The problem remains.

I’ve printed out the file referenced in the for loop (i) as compared to the actual image files in the directory it’s pulling from. Here’s (all 126 of) what I get:

fNum: 0 = 093.png
fNum: 1 = 117.png
fNum: 2 = 112.png
fNum: 3 = 071.png
fNum: 4 = 102.png
fNum: 5 = 068.png
fNum: 6 = 028.png
fNum: 7 = 121.png
fNum: 8 = 118.png
fNum: 9 = 039.png
fNum: 10 = 006.png
fNum: 11 = 110.png
fNum: 12 = 031.png
fNum: 13 = 061.png
fNum: 14 = 011.png
fNum: 15 = 008.png
fNum: 16 = 096.png
fNum: 17 = 069.png
fNum: 18 = 017.png
fNum: 19 = 001.png
fNum: 20 = 032.png
fNum: 21 = 027.png
fNum: 22 = 049.png
fNum: 23 = 089.png
fNum: 24 = 026.png
fNum: 25 = 014.png
fNum: 26 = 010.png
fNum: 27 = 050.png
fNum: 28 = 077.png
fNum: 29 = 034.png
fNum: 30 = 122.png
fNum: 31 = 055.png
fNum: 32 = 083.png
fNum: 33 = 058.png
fNum: 34 = 066.png
fNum: 35 = 088.png
fNum: 36 = 059.png
fNum: 37 = 022.png
fNum: 38 = 098.png
fNum: 39 = 090.png
fNum: 40 = 003.png
fNum: 41 = 016.png
fNum: 42 = 009.png
fNum: 43 = 101.png
fNum: 44 = 114.png
fNum: 45 = 013.png
fNum: 46 = 104.png
fNum: 47 = 053.png
fNum: 48 = 073.png
fNum: 49 = 078.png
fNum: 50 = 012.png
fNum: 51 = 108.png
fNum: 52 = 020.png
fNum: 53 = 035.png
fNum: 54 = 024.png
fNum: 55 = 023.png
fNum: 56 = 021.png
fNum: 57 = 079.png
fNum: 58 = 076.png
fNum: 59 = 092.png
fNum: 60 = 060.png
fNum: 61 = 094.png
fNum: 62 = 029.png
fNum: 63 = 036.png
fNum: 64 = 106.png
fNum: 65 = 113.png
fNum: 66 = 018.png
fNum: 67 = 125.png
fNum: 68 = 056.png
fNum: 69 = 103.png
fNum: 70 = 063.png
fNum: 71 = 054.png
fNum: 72 = 019.png
fNum: 73 = 123.png
fNum: 74 = 109.png
fNum: 75 = 074.png
fNum: 76 = 025.png
fNum: 77 = 126.png
fNum: 78 = 002.png
fNum: 79 = 097.png
fNum: 80 = 075.png
fNum: 81 = 099.png
fNum: 82 = 033.png
fNum: 83 = 040.png
fNum: 84 = 116.png
fNum: 85 = 115.png
fNum: 86 = 005.png
fNum: 87 = 048.png
fNum: 88 = 120.png
fNum: 89 = 007.png
fNum: 90 = 065.png
fNum: 91 = 045.png
fNum: 92 = 105.png
fNum: 93 = 064.png
fNum: 94 = 091.png
fNum: 95 = 086.png
fNum: 96 = 043.png
fNum: 97 = 067.png
fNum: 98 = 080.png
fNum: 99 = 087.png
fNum: 100 = 124.png
fNum: 101 = 095.png
fNum: 102 = 057.png
fNum: 103 = 047.png
fNum: 104 = 041.png
fNum: 105 = 042.png
fNum: 106 = 046.png
fNum: 107 = 100.png
fNum: 108 = 052.png
fNum: 109 = 107.png
fNum: 110 = 030.png
fNum: 111 = 111.png
fNum: 112 = 119.png
fNum: 113 = 015.png
fNum: 114 = 072.png
fNum: 115 = 037.png
fNum: 116 = 084.png
fNum: 117 = 044.png
fNum: 118 = 085.png
fNum: 119 = 081.png
fNum: 120 = 082.png
fNum: 121 = 062.png
fNum: 122 = 070.png
fNum: 123 = 038.png
fNum: 124 = 004.png
fNum: 125 = 051.png

I’m at my wits end trying to figure out what’s going on. As you can imagine, all my animations (which look great on other platforms) are totally wonky on the rPi - which is ultimately where I need them to work. Apologies if this is a known problem and/or there’s a simple fix - I couldn’t find anything related in my searches.

I’ll keep bloodying my head against the keyboard (which I’m afraid happens far too easily these days), but any thoughts/tips/suggestions/solutions would be MUCHO appreciated!!!

Thanks for reading. I’ll update if I figure it out… jut in case anyone else has similar problems.

R.

Strange. Could you share some code to look at?

Hi!

Here’s what’s running for testing. Stripped to the bones. All in the ofApp.cpp:

#include "ofApp.h"

string      imgFolder;
vector      <ofImage> images;
int         frameIndex;
int         fileNum;

//--------------------------------------------------------------
void ofApp::setup() {

    ofBackground(255);
    ofSetFrameRate(60);

    imgFolder = "anim/_plops";

    ofDirectory iDir;
    int iFiles = iDir.listDir(imgFolder);
    if (iFiles){
        for(int i = 0; i < iDir.numFiles(); i++){
            cout << "fNum: " << i << + " = " + iDir.getName(i) << "\n"; // debug
            // add the images to the vector
            fileNum = iDir.numFiles();
            string filePath = iDir.getPath(i);
            images.push_back(ofImage());
            images.back().loadImage(filePath);
        }
    }
    else printf("can't find image directory!\n");
}

//--------------------------------------------------------------
void ofApp::draw() {

    frameIndex = (int)(frameIndex) % images.size();

    ofSetColor(255);
    images[frameIndex].draw(256, 36);

    string info;
    info += "total count: " +ofToString(fileNum)+"\n";
    info += "frame index: " +ofToString(frameIndex)+"\n";
    ofSetColor(0);
    ofDrawBitmapString(info, 15, 20);
}

//--------------------------------------------------------------
void ofApp::keyPressed(int key){
    if(key == OF_KEY_LEFT){
        if (frameIndex <= 0){
            frameIndex = fileNum;
            frameIndex --;
        }
        else frameIndex --;
    }
    if(key == OF_KEY_RIGHT) frameIndex ++;
    cout << frameIndex << " out of " << fileNum << "\n";

    // check for less than zero...
    frameIndex = MAX(frameIndex, 0);
}

Surround code with ```. I fixed your post for you.

It appears that linux version must be listing files in a different operating system order.

You could try ofxIO (which has several options for listing files from the filesystem alphabetically, etc) or – if you already know the names of the files and they are sequential, just load them like this:

int totalNumFiles = 100;

for(int i = 0; i < totalNumFiles; i++){
    images.push_back(ofImage());
    images.back().loadImage(imgFolder + "/" + ofToString(i) + ".png");
}

Also, here’s the method in ofxIO that might be useful:

One other thing – IMHO ofDirectory should return the names of files in a consistent order across platforms. If you can put together a bare bones example to demonstrate that this is not happening consistently, please file an issue. This may be fixed with the new file path updates for 0.9.0, but it should be tested.

Wow, take the dog out for a walk and look at the gift that arrives! Thanks for helping send me along a more proper path. And yes, ofDirectory is inconsistent. Running the identical code on Win7 produces the expected ordering, and things animate as they should. I agree, it would be good if ofDirectory worked cross-platform…

1 Like

The warning you are getting leads me to believe that the image was not loaded correctly, and thus the texture was not loaded … thus the GL renderer error.

You should probably check to see if the simple way is working by checking for correct image loading. The loadImage method returns true on success, false on failure. e.g.

int totalNumFiles = 100;

for(int i = 0; i < totalNumFiles; i++){
    images.push_back(ofImage());
    
    std::string filePath = ofToDataPath(imgFolder + "/" + ofToString(i, 3, '0') + ".png", true);

   if (images.back().loadImage(filePath) == false)
   {
        std::cout << "The image file " << filePath << " could not be found." << std:endl;
   }
}

My guess is that the path was not correct in my original code or one of the items in your sequence was missing … or was not correctly zero padded.

To zero pad, you can use ofToString(i, 3, '0') to make sure your strings are padded (e.g. 001.png, 002.png, etc).

Yep! I did a batch rename in Linux and started on 1 instead of 0 so my count was off. Doh!

Anyway, once corrected, it not only properly loads, but more importantly, I’m seeing the same frames being drawn in the same sequence x-platform. So a very significant step! Thanks a TON for your help!

1 Like

Curious if this changes the behavior

ofDirectory iDir(imgFolder);
int iFiles = iDir.listDir();

will check asap, i’m currently stumbling along trying to figure out how to force a small .c library to load from the /home/pi/ dir in oF by modifying the projects config.make file… (in order to circumvent the formal addon process for basic testing purposes)…

nope, that method also fails on the rPi/linux side. here’s two outputs (first PC running Win7, second rPi2 Model B/raspbian 3.18 distro):

1 Win7:
fNum: 0 = 0000.png
fNum: 1 = 0001.png
fNum: 2 = 0002.png
fNum: 3 = 0003.png
fNum: 4 = 0004.png
fNum: 5 = 0005.png
fNum: 6 = 0006.png
fNum: 7 = 0007.png
fNum: 8 = 0008.png
fNum: 9 = 0009.png
fNum: 10 = 0010.png
fNum: 11 = 0011.png
fNum: 12 = 0012.png
fNum: 13 = 0013.png
fNum: 14 = 0014.png
fNum: 15 = 0015.png
fNum: 16 = 0016.png
fNum: 17 = 0017.png
fNum: 18 = 0018.png
fNum: 19 = 0019.png
fNum: 20 = 0020.png
fNum: 21 = 0021.png
fNum: 22 = 0022.png
fNum: 23 = 0023.png
fNum: 24 = 0024.png

2 rPi:
fNum: 0 = 0008.png
fNum: 1 = 0023.png
fNum: 2 = 0015.png
fNum: 3 = 0009.png
fNum: 4 = 0010.png
fNum: 5 = 0003.png
fNum: 6 = 0007.png
fNum: 7 = 0019.png
fNum: 8 = 0004.png
fNum: 9 = 0024.png
fNum: 10 = 0002.png
fNum: 11 = 0017.png
fNum: 12 = 0016.png
fNum: 13 = 0018.png
fNum: 14 = 0006.png
fNum: 15 = 0011.png
fNum: 16 = 0005.png
fNum: 17 = 0013.png
fNum: 18 = 0021.png
fNum: 19 = 0014.png
fNum: 20 = 0020.png
fNum: 21 = 0012.png
fNum: 22 = 0022.png
fNum: 23 = 0000.png
fNum: 24 = 0001.png

have you tried iDir.sort();

not sure if it matters before or after listDir()

nope, will try a bit later, just changed the code back to test something else - and have to grab a bite to eat! will follow up though. i’d like to get that method working so file numbers aren’t hard coded any more. thanks for being curious…

both windows and osx list a directory in alphabetical order by default but not linux’s ext4 file system, that’s why you get totally random order. the example should be calling sort() after listDir() as @jvcleave points out

1 Like

to think it all boiled down to a simple “sort()” … boy, the time i waste. thanks again all.don’t get why linux wouldn’t use a default ordering of some sort when no “sort()” command is specifically given, but so it is. here’s a simple guide that explains the sort() command if anyone else stumbles into this thread:

Linux and Unix sort command