Pi3D as alternative image extension?

Welcome to the forum @sapnho, great to see you here.

I’ve briefly looked at your website. It’s amazing to see all of the information you have collected on digital picture frames. I’ve seen in one of your guides you are recommending Pi3D (based on Python) to display images with smooth transitions. I’m wondering if this could be a good alternative for Openframe too. And I was hoping you might be able to answer a few questions.

The image extension of Openframe has a few disadvantages:

  • Needs a very high memory split as it is using a shader.
  • Doesn’t work with very large images.
  • Doesn’t support GIF.

How does Pi3D handle these things?

Do you know if it’s possible to attach command line parameters to Pi3D instead of setting a folder path in the code? In Openframe new artwork is generally pushed one-by-one to the frame via web app/server.


1 Like

Hi Jerry, thanks for a great project and forum! I have asked Paddy, the brain behind Pi3D, to reply to your questions because he knows it best!

1 Like

Hi, I will admit here that I don’t know very much about openframe so take that into account if I seem to over-sell pi3d and under-sell openframe!

Openframe seems to be a very professional web orientated, image management and display system whereas pi3d is really ‘just’ a way for python to access GPU functionality. @sapnho’s PictureFrame app is a single script with an awful lot of functionality bundled into it (because it’s evolved over quite a time). But that works because python is such a (relatively) easy language to do that kind of thing.

In compiled languages such as C (or precarious ones such as javascript (actually I’ve come to quite like js!)) it is normal to either pass command line arguments or have a setup file. But in python I’ve found that it’s just as easy to modify the program itself (having made a backup copy first of course). Having said that it’s very easy to read command line arguments, so in the PictureFrame.py app I would:

import sys
if len(sys.argv) > 1:
    PIC_DIR = sys.argv[1]
    PIC_DIR = '/home/pi/pi3d_demos/textures' #or wherever you want to default

Or add the argument on the end as a subdirectory etc. A resent question was how to do something similar to change the picture directory using MQTT messages and it’s a similarly simple change of only a couple of lines.

On your other questions: pi3d also uses shaders - but they’re pretty efficient c.f. ones written in the expectation of a more powerful GPU. And pi3d needs a reasonable memory split - but 128MB should be fine - that’s enough space for two textures 2000x2000 (foreground and background for transition effects). If images are too big then it might cause problems but pi3d will resize to match one of the ‘magic’ numbers that the earlier GPUs relied on. (You can tell it not to if using the RPi4 and you manage the image sizes yourself)

pi3d uses PIL (now Pillow) for image reading and that has most image types available (though I’ve not tried many) https://pillow.readthedocs.io/en/5.1.x/handbook/image-file-formats.html

Anyway, glad you’re interested - let me know if you’ve any other questions.



Thanks a lot @paddywwoof for replying so quickly.

Seems like the command line aspect would be easy to solve.

Seems like Pi3D works very similarly to the openframe-image extension but it’s great that it has a resize feature which sounds more bullet proof than what we have atm.

Looking at the list of file formats it seems like animated GIFs are supported. That’s great. @jon and I had been looking for a CLI based GIF player before but couldn’t find one: Support for animated GIFs

I don’t have time to get into this at the moment but it would be great to keep this in mind. If anyone could confirm the animated GIFs, that would be fantastic.

Again, thanks a lot, Paddy.

@Jerry I’ve not looked at GIFs before (well, not in the context of pi3d and slideshows) but PIL looks to cope with them relatively easily. The PictureFrame app would need something along the lines of

    im = Image.open(fname)
    if im.is_animated:
        for i in range(im.n_frames):
... # rest as per usual
            tex = pi3d.Texture(im, ...

Of course there’s a bit of complexity sorting out the picture sequence. At the moment there’s a number incremented as each picture is shown but the multi-frame GIF files this would have to stall and a frame counter tick over as above. But probably not difficult at all to fix.

Let me know if you want me to make a working version.


1 Like

Thanks for elaborating this.

Of course, that would be amazing. Maybe it would be good to hook Pi3D up into an Openframe extension first to make sure there is nothing else that could be a problem. The current image extension could be a good starting point for a Pi3D extension. It shouldn’t be too hard to set it up.

Again, it would be fantastic if you would do this.