Loading photos from a USB stick
The 'simple' approach is to just load one photo at a time, from whatever USB stick is plugged in, and display it (using the -a flag in fbi to auto-convert to the display resolution).
The problem with this approach is that fbi is rather slow at resizing and this can mean it's still 'reading' the 'old' image buffer.jpg well after you 'switched' the display alias to the new buffer.
This means we need to adopt the rather more clever approach of copying the photos from USB and resize them to the actual display resolution.
Plainly we should only ever save display resolution jpg's, not the full resolution originals. Fortunately, the ImageMagick 'convert' utility is well capable of handling this
Version 1' will just fetch from the usb stiock 'root', resize and save to sdhc card. Dulticate file names will simply be overwritten
Later we need to consider how to handle 'same names', consider how to provide a way to 'delete' unwanted image files and deal with running out of SDHC space ... One obvious way to 'delete' is to place '0 byte' files of the same name on a USB stck and then 'load' that
Displaying photos from a USB stick (USB thumb-drive)
Details of the fetch-resize.sh script are given below :-
The script given works fine, however the following requirements are TBD :-
Duplicate filename detection. Existing files of the same name are simply overwritten. Since (all) photos will be processed to obtain a display resolution jpeg, we can't just compare the source file date with the saved file date - instead the 'saved' photo will be 'date named' (by adding the 'source' file date to the source file name to form the saved (display) file name) USB in use (photos being loaded) LED See next page Running out of space Whatever size SD card you start with, sooner or later you will run out of space. This means adopting a naming convention that will allow old photos to be identified
File naming
A typical 'converted to display' 1280x1024 .jpg will be less than 500kb (mine are 200-300kb). Assuming you start with an 8Gb SDHC, you will have at least 4Gb space to store display images. Even at 0.5Mb each, that means room for at least 8,000 ! Use a 16Gb card and you have 12Gb of display space = 24,000+ photos. So you can 'put off' coding the script to 'delete the old to make way for the new' for some time.
The 'convention' I have adopted is to start the display name with add an alpha-numeric date (YYYY-MM-DD-)
This means a simple 'alphabetic' sort (directory listing) will order the display files with the 'newest' first (whilst a 'reverse alphabetic' sort will place the oldest first).
Immediately following the date, the 16 alphanumeric md5 ID string is inserted, follwoed by an underscore ('_').
Everything after the '_' (and before the first '.') is then used as the description
Note that, having the original date as part of the display image file name, means you have a choice when it comes to deciding 'what is the oldest image'. You can choose 'oldest by original file name' or 'oldest loaded from USB stick' (by checking the display image creation date)
Sample code - getting a directory listing
# get a (new) list of all the image types (that fbi can cope with) in PHOTODIR
find -type f | egrep -i "(jpg|bmp|png|gif}$" > photos.txt# add all .jpg in PHOTODIR to an existing photos.txt list
find $PHOTODIR -iname "*.jpg" >> photos.txt
Todays date ?
One problem with the Pi is that it has no 'real time clock'. This means every time you turn it on it has to discover 'todays date'. If you have an Internet connection (Model B with Ethernet, Model A with WiFi) this is no problem (it uses NTP, just like a Windows PC) - however your photoframe will typically be a 'stand-alone' system !
If you have Raspbian, a utility called 'fake-hwclock' is used to record a timestamp at regular intervals. This means that, on reboot, the Pi will continue from the time it reached just prior to the last shut-down (if not, it reverts to 1 January 1970 (aka Unix epoch)).
Does it matter ? well if you intend to use the display image creation date to decide which 'old' file to remove to make room for new images, then yes ...
You can manually set the 'correct' time by finding the 'fake-hwclock' data file ( /etc/fake-hwclock.data) and changing it's contents.
NOTE that UNIX system clocks run in UTC (and the system adjusts the value to the local time-zone prior to use / display, as necessary)
You will have to kill the hwclock process to get acccess to the file (and then reboot for your manualy entered value to take effect) = so the 'best' you can do is get within a few seconds of the 'real' time (hwclock may also 'drift' a little)