.EXECUTIVE SUMMARY:
The Raspberry Pi's default image viewing program is GPicView – generically referred to as "Image Viewer" in the menu system. This software, which has not been significantly updated in nearly 10 years, ships with all standard "Desktop" versions of the Raspbian operating system.

Although it may be adequate for very basic and occasional image viewing, its behavior is not even slightly customizable. Among many limitations, it doesn't support human-friendly "natural sorting". For example, it insists on displaying image 1 AFTER image 10. It also has no "repeating key" functionality if your folder contains more than 500 images. So if you need to rapidly view hundreds or thousands of images by simply holding down the "next image" key, you're out of luck. It also lacks other basic features of modern image viewers – like the ability to automatically display images in full-screen mode, or display a slideshow of pictures inside a folder.

The good news is that there's a much more powerful and flexible image viewer that's available for the Raspberry. It's known as "feh" and it's completely free and open source.

There's a catch, however: Like many potent solutions in the Linux world, it caters to "command line nerds". These technically sophisticated users often prefer a text-based Terminal screen over a windowed environment like Microsoft Windows or the Mac – a state of affairs that leaves many everyday users out in the cold.

Fortunately, I've now written a script that automatically builds the very latest version of feh AND makes it behave in a highly customizable "windows-like" manner.

It will only take 15 SECONDS of your time to get all the advanced image-viewing capabilities in my tutorial! That's because you only need to do 2 simple things:

Paste my automatic script into Terminal – about 5 seconds of total effort. And then type 2 words and check a box in the "Open With" window – about 10 seconds of total effort.

That's it!

That's a grand total of only 15 seconds to set everything up! The script itself takes about 3 minutes to run – but that's an automated process that does not require any effort on your part.

The reason I'm being so thorough is that I've come to anticipate the many questions I would otherwise get if I didn't explain and document everything so carefully. This is due in part to my considerable experience maintaining my much bigger FFmpeg / mpv tutorial – as well as my other tutorials, such as my "update NOOBS" sticky at the top of the General Discussion room, or my file sorting tutorial in the General Programming room.

Remember also – first and foremost, this is a TUTORIAL. Its main purpose, beyond providing a high-quality image viewing experience, is to show people HOW to do things on their Raspberry. If I just said "yo, here's a script!" and didn't explain anything, that certainly wouldn't be a tutorial. It would be just a random bunch of unexplained code.

IS FEH REALLY THE #1 IMAGE VIEWER FOR THE RASPBERRY PI?
Saying something is "#1" is admittedly a subjective statement. But I can honestly say that feh is the meanest, leanest, fastest image viewer I've ever encountered on the Raspberry. Just as importantly, its behavior is HIGHLY customizable.

As a result of imaging experiments I conducted with a Raspberry-based surveillance system in my backyard, I have personal experience in rapidly reviewing and "digesting" up to 100,000 high-definition images in a quest to find a needle in a haystack – a "bird in flight" image sequence!

Because no $35 computer is really designed to handle that kind of massive image volume, I had to develop an entire workflow that would make it possible. After extensive research and testing of competing solutions, it became clear that only feh had the raw power to meet my demanding needs.

THE IMPORTANCE OF NATURAL SORTING:
The initial inspiration for this tutorial was a genealogist who recently posted a question on my file sorting tutorial. Although I previously developed a whole series of advanced techniques to sort files by renaming them, I've now turned my attention to "viewing sorted files" in a completely passive, "non-destructive" manner that does not rename or touch the files in any way.

In the case of the genealogists, they had purchased a dozen Raspberries to analyze a large volume of census imagery – more than half a million scans of birth, death and other records to determine genealogical histories. Unfortunately, the team of genealogists were constantly flummoxed by the non-intuitive order in which the Raspberry's default image viewer displays images – such as listing page 6 AFTER page 686, and page 1 AFTER page 10.

The reason for this is that GPicView does not observe human-friendly "natural" sorting order.

There is, however, an underlying logic to GPicView's behavior: 1 and 10 both begin with a "1" – just like Apple and Aardvark both begin with the letter "A". Other numbers that don't begin with "1" – such as 2 and 23 – are treated as members of different "groups" and are therefore clustered together separately.

To make things even more confusing, the Raspberry's default file browser – the program known as File Manager – does indeed observe natural sorting order!

It stands to reason that most people would appreciate the basic ability to scroll through an alphanumeric list of names or page numbers in File Manager, double-click whatever they're interested in, and then conveniently move to the next LOGICAL image by simply tapping the right arrow key or spacebar inside the image viewer. Unfortunately, that's when non-intuitive things happen – like image 1 appearing AFTER image 10.

The good news is that my implementation of feh resolves all of that with automatic natural sorting. But before I continue, here's a detailed study I conducted of file sorting behavior on the Raspberry Pi:

To view this image at full resolution, right-click and select "open image in new tab" – or on phones and tablets, "tap and hold" and save it to your pictures for full-size viewing.

SO MIKE – WHAT, SPECIFICALLY, DOES YOUR TUTORIAL AND SCRIPT OFFER?
Glad you asked! My solution offers many benefits beyond automatic natural sorting. In fact, the question from the genealogist was merely the first step down the rabbit hole. That's because it led me to completely re-evaluate the entire image-viewing experience on the Raspberry Pi.

I'm glad this matter came up – because this tutorial now provides a high-quality solution for viewing images in the same comprehensive way that my FFmpeg / mpv tutorial provides for video and audio. Together, they provide a full-spectrum solution for all major forms of media.

My automated script gives your Raspberry 4 major things:

1: LATEST VERSION OF FEH: It builds and installs the latest version of feh from raw source code.

2: FEHVIEW: Because feh is an excellent but geek-oriented image viewer, my script creates a new system command that I call "fehview". It makes feh behave in a "GUI-friendly" manner. This means feh will automatically open images directly from File Manager in the same way that any "windows" program would. But you will NOT have to personally use or understand this command: It simply runs quietly in the background anytime you open an image. IT JUST WORKS!

3: FEHSHOW: My script also creates a second system command that I call "fehshow". This is also a command you don't need to "understand" or "use". It simply allows you to create a brand-new right-click option in File Manager that turns pictures or images inside any folder into an instant full-screen slideshow!

4: CONVENIENT AND HIGHLY CUSTOMIZABLE SETTINGS: My script automatically creates 2 feh-related "buttons" on your Desktop. One is called "Image Viewing Settings" and the other is called "Slideshow Settings". Double-clicking either of these will instantly display the "guts" of my 2 commands (fehview and fehshow) – thus allowing you to quickly and easily change the behavior of feh in image viewing mode or slideshow mode! For example, if you don't want feh to automatically enlarge smaller images to fill up your display, just switch that option off! Or if you want a more rapid slideshow that displays a new image every 5 seconds instead of every 3 seconds, just change the delay value from "3" to "5". Feh has an astonishing number of individual options – 63 in total. When multiple options are combined at the same time, thousands of distinct behaviors are possible! This represents an insane level of customization and control that goes far beyond the Raspberry's "off the shelf" image-viewing capability.

COME ON MIKE – SHOW US A FANCY CHART THAT REVEALS THE BENEFITS OF YOUR LATEST SCRIPT!
OK, fine – if you insist! Here's a detailed feature comparison between the Raspberry's "off the shelf" image-viewing solution (GPicView) and my feh-based solution:

To view this image at full resolution, right-click and select "open image in new tab" – or on phones and tablets, "tap and hold" and save it to your pictures for full-size viewing.

WHAT EXPLAINS FEH'S DIFFERENT DISPLAY RATES IN YOUR CHART?
I conducted all image display rate tests with a 1080p monitor and a Raspberry Pi 3B+ (after a clean boot and a good minute to let the system fully settle down). All test images were JPGs of outdoor scenes with lots of complex geometry.

In the case of my 960 x 540 tests (exactly 1/4 of a 1080p image), "fill screen" means I'm using feh in "auto-zoom" mode. In other words, although the images have a modest resolution of only 960 x 540, I'm forcing feh to enlarge their displayed size so that they completely fill up my 1920 x 1080 screen! This requires continuous interpolation and is therefore much more computationally intensive than simply displaying the image at its actual size. Because of this need to continuously "render" 1080p images from 540p inputs, performance drops by a factor of 3 (from 30 FPS to 10 FPS).

You can also see that even when keeping a smaller image at its actual size, the simple act of placing the image in "full screen mode" causes a modest drop in performance (from 30 FPS to 26 FPS). Although no interpolation is occurring in this instance, feh still has to keep the image centered while maintaining a pure black background that surrounds the image.

Finally, there's a reason why 1080p images have a rather slow 10 FPS display rate – despite the fact that 1080p images perfectly match my monitor's resolution and therefore don't require any resizing or added background in full-screen mode. It's because I'm using a $35 computer! The Raspberry is extraordinarily capable for its price, but it's certainly not a $3,500 computer! A 1080p JPG is a lot of data to continuously de-compress and display. Also, keep in mind that unlike my GPU-accelerated build of mpv, feh's heavy lifting is occurring "in software". In other words, it's doing its calculations in the general-purpose CPU, not the GPU.

WHY DID YOU GIVE GPICVIEW AN "N/A" FOR ALL THE DISPLAY RATES?
If anything, I was being generous when I indicated "N/A (Not Applicable)" for GPicView's image display rate. Here's why: If you need to rapidly view images in a folder – by holding down the right arrow key or spacebar – GPicView will completely lock up and do nothing if the number of images in your folder exceeds 500.

Up to about 200 images or so, GPicView actually maintains a respectable display rate that's almost as good as feh (about 28 FPS). But if there are 300 to 400 images in the folder, the display rate doesn't just slow down – it actually "drops frames". In other words, entire pictures are simply skipped over and not even displayed.

But if you have 500 or more images in your folder, the display rate drops to 0 FPS! It simply locks up (unless you release your finger and manually re-tap the key as fast as you can – a totally impractical solution). And that's when the images have a resolution of only 960 x 540. GPicView chokes up even worse if the resolution is higher.

How do I know these things? Lots of careful observation and testing!

Feh, on the other hand, is simply not intimidated by the number of images you have in a folder. In fact, in my testing of 100,000 JPG images, feh's display rate was completely unaffected by image count.

TECHNICAL COMMENTARY ON THE DISPLAY RATES OF OTHER IMAGE FORMATS:
Here are some observations on other image formats – and how their particular characteristics affect FPS performance:

PNG images are much more "computationally intensive" to de-compress and view than JPG images – especially when set to the maximum compression setting of "9" (which is also the most common setting you'll typically find). The main bottleneck with PNGs would therefore be the CPU. This results in a much slower display rate compared to JPGs. In my testing, 1080p PNGs with complex scenes averaged 3.0 FPS in full-screen mode.

Realize also that although PNGs use compression, they are still a lossless format – unlike their lossy JPG counterparts. They therefore tend to produce a much bigger file than a roughly equivalent JPG. In very general terms, a typical PNG file at the highest compression setting of "9" will usually be about 3 to 10 times bigger than a JPG of the same resolution. Nonetheless, in most cases with PNGs, the data-rate issue is still likely to be secondary to the computational issue in terms of its impact on FPS.

[Just to make things even more complicated, in certain specific scenarios that happen to play to the compression strength of PNGs, they can actually be several times smaller than a JPG!]

In the case of a raw TIF image, however, there is typically no compression – so "computation" would not be the primary bottleneck. Instead, the limitation would be "data rate". A single 1920 x 1080 raw TIF image takes up a whopping 8.3 MB of data. That's because it's losslessly capturing 2.1 megapixels, with no compression, at 32-bits (8 bits for each of the RGB color channels + 8 bits for the transparency alpha channel).

That would be a real problem on the Raspberry.

To give a ballpark sense of the Raspberry's data-rate limitations, I know from real-world testing that a 3B+ can only transfer about 15 MB of data per second when using high-end Samsung flash technology. To be specific, I'm talking about copying a single, contiguous file (like an MP4 video from the internal SD card to a USB thumb drive). File transfer rates can easily drop below 10 MB per second if you're transferring multiple files.

Data transfer, however, involves a "read + write" – a more time-consuming process than simply viewing images (which only requires a "read").

Nonetheless, despite my expectation that "read only" image viewing would be faster, I was still astonished at how fast feh was at displaying 8.3 MB TIF images: My tests consistently demonstrated a display rate of 5.8 FPS. That's an implied data rate of 48 MB per second! [5.8 x 8.3]. That's so unbelievably fast for a $35 computer that I almost wonder if feh was somehow anticipating that I was about to hold down the right-arrow key to rapidly view my test images – and was therefore pre-loading some of the images into RAM to make things go extra fast! I have no evidence of this, but it does make me wonder.

Finally, just to go "full nerd" on the topic of FPS rates, there's a giant elephant in the room that I haven't mentioned. With a few notable exceptions, such as the GCC compiler, almost every piece of software on the Raspberry primarily relies on sequential programming techniques. In other words, the code is not written to take full advantage of the kind of parallel processing that the 4 cores in the Raspberry's CPU can theoretically provide.

[This is not unique to the Raspberry, by the way – many pieces of software, on many different computing systems, are like this for a very simple reason: In general, truly parallel programming is a lot harder to do than serial programming!]

This is clearly evidenced when I hold down the "next image" key and force feh to rapidly display 1080p images. Whether it's JPGs, PNGs or TIFs, the CPU's total activity never exceeds 33% (and sometimes drops below 25%). This indicates that no more than 1/3 of the Raspberry's total theoretical processing power is being used. In other words, only one core is ever at full throttle.

BOTTOM LINE #1: If you want high display rates on the Raspberry, you definitely want JPGs! They represent the perfect blend of low-intensity de-compression and modest file size.

BOTTOM LINE #2: None of the FPS limitations I've discussed have anything to do with my solution or feh itself. Any standard image viewer – no matter how good it is – would find itself hitting these fundamental hardware limitations on the Raspberry.

WHY NOT INSTALL FEH THE "OFFICIAL" WAY?
Some might be wondering why they should use my script when they can just install feh from the official Raspbian software repository by running "sudo apt-get install feh". That will indeed give you a perfectly good copy of feh. Unfortunately, it comes with a giant catch – the version you'll get is now more than 2 years old! To be specific, you'll get version 2.18, which was released on November 1, 2016. For comparison, my script builds version 3.0 – a brand-new version that was released just a few weeks ago.

Older software is now typical of what's available in the Raspberry's official software repository. To be clear, however, this is a deliberate feature, not a flaw. There's a reason why the Raspberry's operating system is so dependable – it's precisely because it's based on the conservative, two-year release cycle of Debian Linux. It takes a long time to make sure thousands of programs "play nice" together and don't have unanticipated consequences.

But like any approach, there are pros and cons. In the case of image viewing on the Raspberry, a major advance occurred only 8 months ago in March of 2018. That's when feh added automatic natural sorting to its formidable list of capabilities. So if you want that feature – and many others that have since been added – your only option is to build the latest version of feh from source code. That's exactly what my script does. But it does something else as well that's just as important – it also installs my fehview and fehshow commands that greatly enhance its versatility on the Raspberry.

WARNING #1:
Before you run my script, let me issue a quick "software conflict warning" to those out there who may have already experimented with a previous version of feh. Like most software, multiple versions of feh will not peacefully coexist: So if you previously installed feh from the repository via "sudo apt-get install feh", simply remove it by running "sudo apt-get remove feh". And to the few out there who may have conducted source code building experiments with feh, be sure to properly remove it – by running "sudo make uninstall", for example, inside the build folder (and then completely delete the entire build folder).

WARNING #2:
Just as I had to do with my FFmpeg / mpv tutorial, I feel the need to explicitly state that my entire script assumes you have a truly "normal", "standard", fully-updated copy of the desktop version of the Raspberry's standard operating system – Raspbian Stretch.

So if you're the kind that likes to "tinker" and customize your system in ways I obviously can't anticipate, I make no guarantee about anything! But I can say one thing with extreme certainty: My script has been thoroughly tested, personally by me, on a "clean" copy of Raspbian Stretch. It works perfectly! So if you encounter any problems, it has absolutely nothing to do with me! [haha].

Finally, all my testing was conducted on a Raspberry Pi 3B+, but it will also work fine on models 3B and 2 (with somewhat lower image display rates, of course). I won't speculate or make claims about other Raspberry models: I don't own any of them. I therefore have no way of evaluating their performance, or whether my script will even work on them. (Compiling is quite demanding.)

SO DO YOU WANT MY IMAGE VIEWING SOLUTION? JUST RUN MY SCRIPT!
But first, make sure you have an Internet connection and that no other programs are currently running on your system (such as the web browser, etc). It's always a best practice to not have a "distracted" system when doing something intense like compiling software. Also, during the building process you will probably see a pinkish-colored "warning" about an implicit declaration of function ‘strverscmp’. That's a harmless developer-related notification that you can ignore.

Note also that I took the time to annotate each section of my script in plain English. It's a good learning tool for those who wish to learn the basics of building programs from source code. It's one of the main reasons I call this a tutorial!

When you copy my script, be aware of 3 things:

1: Don't forget to include the large blue "curly braces" at the beginning AND end of my code.

2: Don't "overcopy" – the last character you select should be the final curly brace and nothing more.

3: Deep inside my script – the one you're about to copy and paste – I make multiple references to "choosing" and "editing" command lines. That is not intended for you at this point – those are simply instructions that will end up appearing inside the 2 settings "buttons" my script will place on your Desktop. In other words: Do not tamper with my script – just "mindlessly" paste it into Terminal and let it do its thing! After it's finished, you can adjust your image viewing and slideshow settings any way you want via the 2 Desktop "buttons" that you will soon have.

That's it! So copy my long block of code – then right-click inside the Terminal window, click Paste, and hit the Enter key! It will only take about 3 minutes for my script to do everything. When it's finished, the command prompt will re-appear:

{##### This first part of my script installs 9 "dependencies" – standard software packages from the official Raspbian repository. These packages are needed to build the feh program from its source code. This, by the way, is the most time-consuming part of my entire script (it will only download less than 25 MB of dependencies from the repository, but the Raspberry will take at least 2 minutes to unpack and install them). And in case you're wondering why I use so many "echo" commands, it's to provide good spatial separation in Terminal's output. That way, when the script is finished executing, it makes it very easy to scroll up and clearly see what happened for each of the main components of my script:

##### The following line creates a brand-new folder on your system called "Feh_Build". That's where all the source code "building" will take place:

mkdir Feh_Build

##### Now we need to download and unzip the raw source code from feh's official website. In this case, it's in the form of a "stable release tarball". By choosing the most recent stable release version, instead of the developmental "git" version, we can know the code is "locked in" and predictable in its behavior:

cd Feh_Build

wget https://feh.finalrewind.org/feh-3.0.tar.bz2

echo; echo

tar jxvf feh-3.0.tar.bz2

cd feh-3.0

echo; echo; echo

##### This is where we build (compile) a working feh program from its source code. We then install it. The "j4", by the way, instructs all 4 cores of the Raspberry's CPU to work on this task simultaneously – a rather impressive capability for a $35 computer! It should only take about 30 seconds:

make -j4 exif=1

sudo make install

sudo ldconfig

echo; echo; echo

feh -version

echo; echo; echo

##### At this point, the feh program should be fully built and installed. This next step creates my "fehview" command. It will control feh's default image-viewing behavior and allow it to work seamlessly with Raspbian's File Manager GUI. In other words, double-clicking any image file of your choice (such as a .jpg, .png, .tif, etc.) will automatically trigger feh to open them and behave in any manner you desire. A detailed explanation of exactly what this code does appears in the "Explanation for Nerds" section at the end of my tutorial:

echo $'#!/bin/bash

filename=$(basename "$1")

directory=$(dirname "$1")

cd "$directory"

##########################
# INSTRUCTIONS: CAREFULLY CHOOSE ONE OF THE FOLLOWING 3 COMMAND LINES TO CHANGE FEH\'S IMAGE VIEWING SETTINGS. TO CHOOSE A COMMAND LINE AND MAKE IT ACTIVE, SIMPLY REMOVE THE HASHTAG IN FRONT OF THE WORD "feh". HOWEVER, BE CERTAIN THAT ALL THE OTHER LINES STILL HAVE THEIR HASHTAGS (ONLY ONE LINE AT A TIME CAN BE WITHOUT A HASHTAG). OR, IF YOU WISH TO CUSTOMIZE THE SETTINGS TO YOUR OWN LIKING, FEEL FREE TO CAREFULLY EDIT THE COMMAND LINE(S). WHEN YOU\'RE DONE MAKING CHANGES, SIMPLY PRESS CTRL+S TO SAVE THIS FILE:
##########################

##### This next step creates my 2nd command, which I call "fehshow". It commands feh to operate in "slideshow mode", and also determines its behavior while in that mode – such as whether smaller images are automatically expanded to fill the screen, how long each picture is displayed, etc. For example, as you can see below, I chose a "hold period" (delay) of 3 seconds for each picture before it displays the next picture (via feh's -D 3 option). You can even set the delay to only 0.1 seconds for a rapid display effect. But don't change any of these settings now – leave everything alone and run my script "as is":

echo $'#!/bin/bash

cd "$1"

##########################
# INSTRUCTIONS: CAREFULLY CHOOSE ONE OF THE FOLLOWING 2 COMMAND LINES TO CHANGE FEH\'S SLIDESHOW SETTINGS. TO CHOOSE A COMMAND LINE AND MAKE IT ACTIVE, SIMPLY REMOVE THE HASHTAG IN FRONT OF THE WORD "feh". HOWEVER, BE CERTAIN THAT ALL THE OTHER LINES STILL HAVE THEIR HASHTAGS (ONLY ONE LINE AT A TIME CAN BE WITHOUT A HASHTAG). OR, IF YOU WISH TO CUSTOMIZE THE SETTINGS TO YOUR OWN LIKING, FEEL FREE TO CAREFULLY EDIT THE COMMAND LINE(S). WHEN YOU\'RE DONE MAKING CHANGES, SIMPLY PRESS CTRL+S TO SAVE THIS FILE:
##########################

##### This final section creates 3 feh-related items that will appear on your Desktop. The first is quite simple – it's just a standard text file that contains feh's official manual. The final two are called "Image Viewing Settings" and "Slideshow Settings". These "buttons" provide a quick and convenient way to control the behavior of feh in image viewing mode (fehview) and slideshow mode (fehshow). When double-clicked, the icons will automatically open the "guts" of my script for each command (fehview and fehshow) by launching the Raspberry's standard Text Editor (known as leafpad). I prefaced the leafpad command with "sudo" because the /usr/bin folder is owned by root – thus all files inside it require root-user editing rights. Finally, the sleep period of 1 second between the creation of the Desktop files is the result of extensive testing. Without that delay, the "Image Viewing Settings" icon often ended up below the "Slideshow Settings" icon; I did not want the icons to appear in that less-than-logical order! Even a delay of 0.7 seconds resulted in the wrong order about 20% of the time. Only a full second of sleep was sufficient to guarantee proper order:

ONCE MY SCRIPT HAS FINISHED, YOU NEED TO ASSOCIATE YOUR IMAGE FILES WITH MY FEHVIEW COMMAND:
This is super simple: Open File Manager and right-click an image file – such as a file ending in .jpg, .png or .tif. Then, click "Open With...". When the small window appears, click the "Custom Command Line" tab. In this example, I'll use .jpg to show how easy this is. Simply fill out the window exactly as I'm showing in my illustration: Type "fehview" twice and check one single box! That's it! As you can see, it's easy as 1, 2, 3:

REPEAT the same procedure, if you wish, for .png and .tif images (see my entire section, below, on associating additional image formats if you'd like to know more about that topic). And don't worry about the "spelling" difference, for example, between .jpg, .jpeg, .JPG, and JPEG. The Raspberry's file association system is smart enough to recognize all of them in one shot – so you only need to associate one version of the "spelling" and it will automatically know the rest!

THE FINAL, ESSENTIAL STEP: ASSOCIATE YOUR FOLDERS WITH MY FEHSHOW COMMAND:
This is the final one-time step – very similar to what you previously did for the "fehview" command. Except this time, you need to right-click any FOLDER with pictures inside it! Then, click "Open With" and do the same basic "1, 2, 3" procedure you did for the other command – except this time, instead of typing in the word "fehview", make sure you enter the word "fehshow".

That's it! From then on, any time you right-click a folder, you'll see a new right-click option that says "fehshow"! Just click that and your full-screen slideshow will automatically begin!

CRITICAL NOTE: Posts on this website are limited to a maximum of 3 images. I have therefore included the fehshow graphic in the next post immediately after this one! I did the "1, 2, 3" callouts in blue instead of red – just to make clear that what you need to enter is slightly different.

MY "FACTORY SETTINGS" EXPLAINED:
You don't need to change any settings – unless you want to! If you run my script and don't do anything more, you will automatically get the following "factory settings" that I chose for image viewing. In other words, they are the "default settings" that determine feh's behavior when viewing images. Why did I make this the default behavior? Simple! It's my personal favorite! Here are the main things it does:

1: Full screen mode and nothing else – your entire display will fill up with every image. If the aspect ratio of an image does not match your screen, it will use a pure black background to fill in the empty space. In other words, while enlarging or shrinking images to fill your screen, feh will never distort the height-to-width ratio by squeezing or stretching in one direction. Unless you want it to, of course – as I mentioned, feh can do almost anything you want!

2: If the image is bigger than your display's resolution, it will automatically shrink it to fit your screen (while maintaining aspect ratio).

3: If the image is smaller than your display's resolution, it will automatically enlarge it to fill up your screen (while maintaining aspect ratio).

CUSTOMIZE YOUR IMAGE VIEWING SETTINGS – IF YOU WANT:
Some people, however, may not like my "factory settings". For example, they may want "small" images to be displayed at their actual size instead of filling up their screen. Personally, I like seeing all my images at "maximum possible size". It makes it very easy to clearly see smaller images from a distance. Nonetheless, when you double-click the new "button" on your Desktop – the one that says "Image Viewing Settings" – you can easily change that behavior to match your personal taste. You will also see other "pre-made" options that I provided for your image-viewing pleasure!

I even included a pre-built setting that I personally recommend for the team of genealogists. The option I created for them is exactly the same as my "factory setting" – except feh will also display the name of the file being viewed in the upper-left corner of the screen. That way, the genealogists will always know whether they're looking at "SMITH, page 23" or "SMITH, page 24".

Keep in mind that you are NOT limited to my pre-built selections!

Feel free to look at feh's official manual to make your own custom settings. As I mentioned, feh is extremely flexible and there are thousands of possible configurations! If you run my script, you will automatically have feh's manual on your Desktop. Just be sure not to tamper with the beginning part of feh's command line [feh --start-at ./"$filename"]. Aside from that, you can tweak things however you wish – just be careful not to make any typos, accidentally add extra spaces, or use "bogus" options that do not comply with feh's requirements. Just use common sense and the sky's the limit!

CUSTOMIZE YOUR SLIDESHOW SETTINGS – IF YOU WANT:
You can easily do this by double-clicking the second "button" on your Desktop. It also includes a couple "pre-built" slideshow settings. The "factory setting" I chose is the same behavior I chose for standard image viewing. However, since these settings pertain to a slideshow, we must also have a time setting for the "delay" between each image. It's the "-D 3" item in feh's command line. It controls the delay between pictures in the slideshow. So if you want each picture to remain on your screen for 5 seconds, for instance, carefully change that part to "-D 5". You can also create a rather freaky "rapid slideshow effect" by putting the value all the way down to 1/10th of a second with "-D 0.1".

FEH SUPPORTS MANY MORE IMAGE FORMATS – IF YOU WANT:
Personally, the only raster-based image formats I ever work with are JPG and PNG. Together, they pretty much offer the best of both worlds: JPG offers a high-quality "lossy" format with modest file sizes. And at the cost of larger file size and greater computational demands, PNG offers 100% perfect image replication without any quality loss whatsoever. It also supports alpha transparency.

JPG and PNG are also, by far, the most common and universally-accepted image formats on the Internet. Feh also has built-in native support for TIF and GIF images (however, since it's not an animation or movie-viewing program, feh will only display the first frame of an animated GIF. My build of mpv, by the way, fully supports animated GIFs and will play them just like an MP4 video!).

But if you want feh to support many other image formats, you can easily do that because feh fully supports a powerful "image translation and conversion tool" that automatically comes with the completely free and well-respected ImageMagick program.

This converter "translates" image formats that feh does not natively support and converts them into a feh-friendly format that feh can display! All of this happens "behind the scenes" – invisibly, without any action by the user.

I should also emphasize that this "conversion" is entirely non-destructive. In other words, it does not tamper with or touch the original image AT ALL. It simply does a behind-the-scenes "translation" so that feh can display it!

Be aware, however, that some of the more obscure image formats can be very computationally intensive to translate (taking up to several seconds per image). So if you have a folder that's loaded with a bunch of images in all kinds of obscure and different formats – but all you really want is to display JPGs or PNGs or TIFs at high speed – be aware that invoking the translation tool will slow things down dramatically. However, you can easily toggle the translation capability off or on at any time by double-clicking the settings "button" that my script places on your Desktop!

So, if you want to enable full support for numerous other image formats, switch on the image translation feature by adding this to feh's settings:

--conversion-timeout 20

STOP THE RASPBERRY FROM PUTTING THE SCREEN TO SLEEP EVERY 10 MINUTES – IF YOU WANT!
If you didn't know about this hidden, pre-loaded "feature" of the Raspberry, it could easily drive you crazy – especially if you like to play slideshows or watch movies! That's because the Raspbian operating system, by default, will put your screen to sleep every 10 minutes if it doesn't detect any keyboard activity. The fact a slideshow or movie might still be running is irrelevant – the entire screen will still go blank! I suppose it's a good-intentioned attempt to save a bit of energy and reduce the Raspberry's carbon footprint.

Whatever the case, there's a simple way to permanently disable this behavior. Just run the following command in Terminal (it installs a screensaver utility):

sudo apt-get install xscreensaver

Once it's done installing, you need to REBOOT to let the software fully "kick in". If you don't reboot, the window will typically flash and disappear if you attempt to launch it.

When your system comes back up from the reboot, simply click the Raspberry Menu | Preferences | Screensaver:

On the window that appears, you need to do only ONE thing – just change the "Mode" drop-down box in the upper-left corner from "Random Screen Saver" to "Disable Screen Saver". Then close the window (there's no OK button or anything). And bingo – that's it! Your screen will never go to sleep due to keyboard inactivity!

MOST USEFUL KEYBOARD CONTROLS WHEN USING FEH:Left & Right arrow keys: Move back and forth through all the images in the current folder (you can also use the Backspace & Spacebar for the same purpose). These back and forth keys will even work in slideshow mode (as do many of the keyboard controls).

Up & Down arrow keys: Zoom in and out. This can be fun to use on occasion, but it's probably not a keyboard control that will be used much, given that my "factory settings" automatically place images in "auto-zoom" mode – where images smaller than your screen's resolution are automatically enlarged to fill up your display while maintaining the image's aspect ratio.

f: Toggles full screen mode off and on.

d: Toggles the display of the file name you're currently looking at.

e: Toggles the display of Exif metadata (such as when a picture was taken, its shutter speed, aperture value, etc). Exif metadata is most commonly found with JPG pictures taken by a digital camera; be aware that many images simply don't have Exif metadata – in those cases, this toggle will display "No Exif data in file".

h: Toggles slideshows between pause and play (if you want to temporarily "hold" an image during the playing of a slideshow).

Z (capital Z; typically, this means you'll press Shift + z): Toggles auto-zoom mode off and on. Auto-zoom is where images smaller than your screen's resolution are automatically enlarged to fill up your display while maintaining the image's aspect ratio. This is the default "factory setting", simply because I personally like that mode – but you can obviously switch it off with the Image Viewing Settings "button" on the Desktop. It's the "--zoom max" part of feh's command line.

> (typically, this is Shift + the period key): Rotates the image 90 degrees clockwise each time you press it.

< (typically, this is Shift + the comma key): Rotates the image 90 degrees counter-clockwise each time you press it.

Right-Click the Mouse: Displays an on-screen menu so you can choose additional options.

Esc: Escape out of feh and completely close your image-viewing session.

There are many other keyboard controls. The full list appears under the "KEYS" section in feh's official manual (which my script will have automatically placed on your Desktop).

EXPLANATION FOR NERDS – HOW MY FEHVIEW "METASCRIPT" ACTUALLY WORKS:
Why do I call the script that makes my fehview command a metascript? That's because it's a script that creates another script! In this particular case, that "other script" becomes a system command that I call fehview.

The real purpose of my fehview command is two-fold: It addresses the very specific file-handling needs of feh AND tells feh how to behave whenever you open an image.

What follows is an explanation of the underlying technical issues I had to address in order to get feh to work properly with the Raspberry's File Manager:

Feh's "--start-at" option is essential in allowing the user to directly open a specific image inside a folder AND start feh's "filelist" feature at that specific image. Without a properly started "filelist", feh will not be aware of the other images in the folder – and therefore will not allow you to simply tap the right-arrow key or spacebar to move to the next image. In other words, without this feature, you would simply be "stuck" at whatever image you opened – with no means within feh to move to the next or previous image.

You might be thinking at this point "but you just said feh has this nifty "--start-at" option that takes care of all that!" Unfortunately, there's a big catch: The "--start-at" option requires an individual filename, such as "image.jpg" – not the full path to the image, such as "/home/pi/image.jpg". The reason why this is a big deal is that the "%f" field code that File Manager uses in the "Open With" dialog grabs the entire path to the file, not the filename by itself. In other words, the "%f" field code – which, conceptually, can be thought of as the "f variable" – will end up containing the value "/home/pi/image.jpg" (not "image.jpg").

That's why I had to come up with a way to extract the core file name (without the entire path) in order to make it "feh friendly". Fortunately, Linux has the "basename" command that does exactly that! It will automatically extract "image.jpg" from a full path like "/home/pi/image.jpg". As you can see, it does this by operating on the value of the "$1" positional parameter – which, conceptually, can be thought of as the "1 variable". The value of the "1 variable", in effect, inherits the value of the "f variable". In other words, if the file you double-clicked on in File Manager is called "image.jpg", the value of the "1 variable" will be "/home/pi/image.jpg" (since that is also the value of the "f variable").

That alone, however, is not enough to make things "feh friendly". Being a "nerd-centric" command line program, feh of course is designed to focus its attention on the current working directory. Since people will naturally double-click images in whatever folder they choose, this also has to be taken into account. Yet again, Linux comes to the rescue with the "dirname" command. It does the opposite of the basename command by extracting "just the directory" from a file's full path. In other words, it will extract "/home/pi" from "/home/pi/image.jpg".

I then assign those values – image.jpg and /home/pi – to the respective variables named "filename" and "directory".

Once that's done, it's a straightforward matter of using the "cd" command to enter the proper directory – the exact same folder in which the image was double-clicked.

At that point, I can use the feh command as though I were using it as a standard command line inside Terminal! This approach gives me tremendous flexibility in making feh behave any way I want.

As you can see, I feed the "--start-at" option with the value of the "filename" variable – along with any other default options I want feh to have – such as automatically placing images in full screen mode with the "-F" option, hiding the mouse pointer with the "--hide-pointer" option, and making smaller images "auto-zoom" to fill up the entire screen!

My next step was to place the internal fehview script inside single quotes for use with the echo command – and then output all that single-quoted text to the /usr/bin folder and give it the filename "fehview". This then becomes my infamous fehview command!

However, because /usr/bin is owned by root, you can't directly output a file to that folder (you'll get "permission denied" if you try). To circumvent that, I use a Linux trick that copies the "standard input" with sudo and pastes it directly into the root-owned /usr/bin folder.

Finally, using the sudo chmod command, I change the permissions of the "fehview" file to a standard executable (755) – thus transforming it into a full-fledged system command that can be used with all image-related file associations!

So there ya go – that's how I did it. Carry on nerds!

Last edited by RPi_Mike on Sat Dec 01, 2018 6:26 am, edited 12 times in total.

.FINAL TUTORIAL ILLUSTRATIONS:
Each post on this website is limited to a maximum of 3 images – yet I wanted to share a total of 6 illustrations. The following 3 graphics therefore complete my tutorial:

You really are a "wonder"! Thank you very much for all the work you did on creating this solution and tutorial. I have sent it to our tech support person and expect he will test it out this coming week.

The volunteers, researchers and Board of the Northeast Pennsylvania genealogical society are very thankful to you and hope you will continue to be such a generous and valuable resource to the Raspberry Pi users for many years to come.

Thank you very much for all the work you did on creating this solution and tutorial ..... The volunteers, researchers and Board of the Northeast Pennsylvania genealogical society are very thankful to you

You're welcome!

I'll be curious to hear what the genealogists think of my image-viewing solution.

This is a fantastic script and a really useful tool, but the install no longer seems to be working..... Any ideas?

I agree with B.Goode's overall sense of things.

For whatever reason, your system – not my script – failed to download or properly install at least some of the critical dependencies that feh needs to compile successfully.

For example, your system appears to be missing the standard development packages related to X11 and Exif. My script simply attempts to acquire those basic items from the official Raspbian repository – a requirement that's as mainstream and standard as anything can possibly get!

However, since it sounds like you're a prior user of my script and you appreciate its value, I just went the extra mile and performed the following "gold standard" test:

Just 10 minutes ago, I created a brand-new, completely fresh copy of the latest version of Raspbian Desktop. I then ran my script while pretending to be a total beginner. In other words, no assumed knowledge whatsoever – I simply followed my instructions to the letter.

And the results?

My script works perfectly, just as it always has.

So my advice is pretty simple:

Just delete the "Feh_Build" folder (at /home/pi/Feh_Build), reboot your Raspberry, and make sure you have a stable Internet connection when it comes back up.

Then, simply re-run my script!

If you're still having problems after that, there's only one major remaining possibility:

YOUR SYSTEM IS MESSED UP!

If that's the case, there's only one SANE option – unless you want to potentially spend hours or days chasing ghosts: Backup any data you wish to keep and NUKE your entire system! In other words, burn a new SD card and create a fresh copy of Raspbian Desktop... and then run my script!

That said, it certainly can't hurt to look at the Terminal session to see if you can make sense of where your system (not my script) is failing. If you have the right combination of expertise and luck, you might be able to fix your system without nuking it. If you can do that, great. If not, however, my advice still stands.

PHILOSOPHICAL NOTE: This is not directed to anyone on this thread, but I feel like saying it anyway: In most cases, I don't support back-and-forth troubleshooting sessions on this website. That's why my typical style is to make a definitive "position statement" and leave it at that! Why? Because I have a deeply-held philosophical conviction:

It's a reasonable expectation that people have a fully-working, completely "normal" copy of the Raspberry's official operating system. If it's not "normal", then we might as well be diagnosing problems on the BBC Micro or the Commodore 64. Because as far as I'm concerned, if it's not a "normal" copy of Raspbian, it's NOT Raspbian – it's a completely different operating system called "Damaged Raspbian" or "Altered Raspbian"!

This aggressive but completely justified attitude has saved me A LOT of frustration in dealing with all the insanity from "random Internet people" on my giant FFmpeg/mpv tutorial. When running complex scripts, it's essential to have TOTAL FAITH in the integrity and predictability of the underlying system. Without that, it's just a big waste of time for all parties concerned – especially when dealing with unknown persons with unknown competencies on unknown systems with unknown histories!

This also explains why I am very PRO NUKE – at least when it comes to computers!

Thanks for the quick reply and I agree with your approach re. support and nuking. The only reason I asked was because it had happened on two in a row from a batch of 12 that had been flashed, updated and upgraded in exactly the same way, so I wondered whether something had changed in the world of Raspbian that had caused the error.

Having re-flashed them both though, the script is working perfectly as before so I'm not sure what caused it.

Mike: Our genealogical society was not able to try your solution to Widows-like file sorting because our tech support person was away for several months. He is now back and will be following your instructions in the next day or two.

He had one question about the FehView. Does it allow for the printing of an image? We often need to do that when a patron finds a digitized image that has valuable information on it.

Mike: Our genealogical society was not able to try your solution to Widows-like file sorting because our tech support person was away for several months. He is now back and will be following your instructions in the next day or two.

He had one question about your fehview command. Does it allow for the printing of an image?

My fehview command simply allows feh to work in a manner that's "GUI friendly" and easily customizable on the Raspberry. My contribution does not alter the internal capabilities of feh itself. In other words, I'm not the developer of feh, nor do I have any say in what it can or cannot do.

But I just did a quick check of feh's official manual; it does not appear to have any feature specific to printing. However, that by itself is not necessarily an issue: If your Raspberry is properly configured and connected to a working printer, a simple tap of your keyboard's "print screen" button should automatically print whatever feh is displaying!

Alternatively, feh also allows you to create your own keyboard "actions". For example, you can tell feh to trigger your printing program any time you tap a particular key — the printing program will then print whatever image file is currently being displayed. However, I have never used a printer on a Raspberry and therefore cannot provide any specific guidance on this (or any other) method — but none of this should be too difficult for a competent "tech support" person. For more details on the "action" approach, please see the following link. In theory, it might allow for a higher-quality "direct printing" of the file itself rather than a "screenshot printing" (that the "print screen" button would normally do):

Beyond this, by asking about printing, you're accidentally stepping into yet another giant can of worms that proves, once again, that Windows is superior to Linux for many mainstream users. Let me explain:

I'm NOT at all suggesting that Windows is "technically" superior or "inherently" superior — because it's not! But it is "effectively" superior in certain key areas for one simple reason — SUPPORT.

Because Windows obliterated Linux decades ago in the "regular computer" consumer space, most leading consumer electronics companies simply don't support it — or if they do "support" it, it's in a highly qualified or limited way. They can't be bothered doing a bunch of costly development work for an operating system that most "normal" people don't even use!

By "normal" people, I'm talking about doctors, lawyers, housewives, and candle stick makers. Ya know — "normal" people. People who simply want to get things done and could care less about computer science or programming or how much fun it supposedly is to be a nerd!

But oh, it gets even worse than that! That's because there's really no such thing as "Linux". Instead, you have dozens and dozens of Balkanized "distributions" of Linux that can vary dramatically. Even within the single world of the Raspberry, there are two main "sub-distributions" of Linux — a "Desktop" version with a GUI and a "lite" version without a GUI! [Most "normal" people, by the way, probably don't even know what a GUI is.]

All of these factors conspire to make any one particular flavor of "Linux" relatively "obscure" and unimportant in the overall marketplace. Bill Gates is still justifiably laughing about this every single day! Linux nerds, who typically lack business and marketing savvy, are great at shooting themselves in the foot — as history amply demonstrates.

As if that weren't enough, the Raspberry is "triple obscure". That's because the few Linux-related drivers and other software that ARE available from consumer electronics companies are almost always x86-based (the CPUs made by Intel and AMD). But the Raspberry has an utterly incompatible ARM-based CPU. ARM may be the "CPU king" of the smartphone revolution (both the iPhone and Android use variants of ARM) — but in the "regular computer" space, ARM isn't even in the game!

[I'm not disparaging the Raspberry, by the way. I personally love it — otherwise I wouldn't have bothered making these tutorials. It's now the best-selling general-purpose computer line in the history of the world — eclipsed only by the Mac and PC! And ARM, as I said, is the "CPU king" of one of the biggest revolutions our species has ever known. Finally, "Linux" is THE preeminent operating system on multiple levels. Nonetheless, everything else I said is still true. What can I say — we live in a complicated and messy universe that never guaranteed things would be simple!]

Linux people can be very clever — at least when it comes to technical matters. So is it possible to get a printer working on a Raspberry? Yes, it's certainly possible. Maybe. It all depends on what make and model you have.

Many people use the freely available CUPS software package to accomplish this. It's basically a nerdy way to sidestep much of what I just discussed. The downside is that most printer manufacturers make little or no effort to support the nerds, so your mileage may vary.

Printing is definitely NOT a topic for this particular forum — but there are several other pages on this website that DO discuss how to get a printer working on a Raspberry. Google, as they say, is your friend. So I would try a search term like this to get started on that subject:

CUPS printer site:raspberrypi.org

Good luck to you and your fellow genealogists. Please post again on this page with your final outcome. I'm very curious to hear how everything turned out!

Thanks Mike! That's a very interesting and thoughtful explanation on printing with the Raspberry.

I suspect the printing question is a red herring because the Raspberry program we are currently using - GPicView - does not have a print function. Besides, the NEPGS staff does not want our clients to print themselves but rather insists that the clients fill out a print request form which is then processed on a Windows pc.

So far, I have only (indirectly) heard that our tech support guy thinks your program might not be as "user friendly" as GPicView. I assume we'll test out both image viewers on side-by-side Raspberries and find out. Our clients are mostly elderly and unsure when using either our pc's or the Raspberry devices.

You are a real treasure for this forum and I appreciate you clear and amazingly quick responses to questions. Thanks, again.

So far, I have only (indirectly) heard that our tech support guy thinks your program might not be as "user friendly" as GPicView. I assume we'll test out both image viewers on side-by-side Raspberries and find out. Our clients are mostly elderly and unsure when using either our pc's or the Raspberry devices.

I'm honestly not sure why anyone would think that about my solution.

To open an image, just double-click it and BOOM — the image appears on the screen!

To see the next or previous image, just tap the left or right arrow key.

It's extremely "user friendly"!

In fact, this behavior is IDENTICAL to GPicView and almost every image-viewing program on Windows.

The big advantage of my solution is that it provides massive control over the default viewing behavior — such as resize to fill screen / do not resize to fill screen; display file name / do not display file name, etc.

But those settings are for the tech support guy to adjust on a one-time basis, if he so chooses — not for the "elderly and unsure" clients to monkey with!

End users of my solution do not require ANY technical knowledge or "computer literacy" whatsoever — other than knowing how to use a finger to press a key and a hand to operate a mouse.

Beyond that, the very beginning of this entire story was that your clients were getting horribly confused by GPicView's insistence on displaying page 6 AFTER page 686, and page 1 AFTER page 10 — due to its total inability to display numbered file names in human-friendly "natural" order. As you know, my solution fixes that gigantic problem. Given that elephant in the room, it strikes me as completely nonsensical that anyone involved with your organization could possibly suggest that GPicView is more "user friendly".

Thanks for your reply. I hope we can soon implement the solution you provided. Unfortunately, our non-profit organization regularly make decisions not based on a financial or logical basis but more on an emotional basis.

When the idea of installing the Raspberry pi devices first surfaced, all of us who had some computer experienced suggested that nothing should be done until a trustworthy, local technical support company or person was in place. That advice was ignored because the Board could see saving money and problems by moving away from our Windows computers.

Now we are trying to work with a support who has remote access to the Raspberry devices. So far, I cannot be sure that he is following you instructions. But I need to give him a few days, since I know we are not his only client.

I hope this will eventually work out, Mike. And I am very grateful for your help and and your creative solution. Please don't give up us as we work through our own problems of communication and priorities. Thank you, Mike.

any reason why you didn't use code tags to make copy/pasting the code easy from this forum?
I can add these tags for you, and remove any current tags that will appear as text inside the code tags. Meaning that the code will appear without any color or size alterations, just as an easy to copy and paste code block.

any reason why you didn't use code tags to make copy/pasting the code easy from this forum?

I agree that a "code box" allows for a slightly quicker copy/paste. But as an author, I like the idea of my code being completely exposed and "out in the open", instead of being "hidden" inside a tiny scroll box that only displays a small number of lines at a time.

This is especially true when I've taken the time to write large paragraphs in plain English — embedded inside my code as red # remarks — that explain exactly what my code is doing at every step. I consider that to be a big part of my overall tutorial writing, because it helps people get a deeper understanding of the Raspberry that goes beyond mere code.

I need to be able to update a jpg image periodically and have the new image displayed.

Can you elaborate on what you mean by "update a jpg image periodically and have the new image displayed"?

In other words, what's your specific "use case" and how are you actually doing this image updating? In fact, what exactly do you mean by "update an image"?

Let's assume for the moment that you're talking about ONE specific image file that a program keeps updating. For example, you might have a webcam that takes a single image of your backyard every 10 seconds by OVERWRITING (and thus "updating") the same image file again and again.

There are some scripting techniques that could, in theory, continuously monitor the image file and "auto detect" the exact moment the file changes — and then trigger a refresh of feh itself each time. But that strikes me as overly complicated for the kind of thing you're probably trying to do.

Instead, I would simply use feh's built-in "image reload" feature!

Before I continue, however, please understand that my fehview and fehshow commands merely enhance the USABILITY of feh on the Raspberry when viewing images via the File Manager — they do not provide the core features of feh itself. I am not the developer of feh.

Also, if you're talking about viewing a single image and not a slideshow, you would want to change the settings of my fehview command — not my fehshow command.

TECHNICAL NOTE: Because this clean but simple method is not monitoring the contents of the file itself, there will of course be a "synchronization" issue. For example, the image might change at exactly 12:00:00.000 — but the next reload might not occur until 12:00:09.999. So a 10-second refresh rate could produce a MAXIMUM delay of 9.999 seconds in a worst-case scenario (it all depends on the arbitrary time that each bit of code starts).

To get even more technical, there's also the separate but related issue of "time drift". Since the various code executions are not being calibrated by an atomic clock, the amount of de-synchronization would constantly vary over time (but would still never exceed 10 seconds).

If any of this matters to you, you can easily lower the reload rate to 5 seconds or even 1 second! In fact, if feh's reload feature behaves as some of its other time-based settings, you can probably achieve sub-second refresh rates by entering a value of 0.1 seconds. That would produce a maximum de-synchronization of 0.099 seconds!

Just to elaborate a bit, I am exporting a jpg file of a screenshot of a FileMaker database layout to a folder on the RPi. The file name does not change, so yes, I am overwriting the existing file. The export occurs periodically as set by a parameter in a script. The RPi is connected to a large display so people in a warehouse can see the image. The database is updated frequently and the warehouse always shows the latest information.

Just to elaborate a bit, I am exporting a jpg file of a screenshot of a FileMaker database layout to a folder on the RPi. The file name does not change, so yes, I am overwriting the existing file. The export occurs periodically as set by a parameter in a script. The RPi is connected to a large display so people in a warehouse can see the image. The database is updated frequently and the warehouse always shows the latest information.

There's something cool in knowing my code is now being used in an industrial setting!

Although the Raspberry Pi was primarily developed with the education market in mind — with some expectation that hobbyists might use it as well — no one anticipated that millions of these little computers would also end up being used in commercial products, factories, warehouses, robots and other industrial applications.

But it makes perfect sense, given how "cheap but reliable" — and small — and power-efficient — and highly customizable — and connectable — and open and free and non-proprietary — the Linux-based Raspberry really is!

Is there a way to run fehshow at power on of the RPi? It would be convenient to not have to right-click the folder manually.

Don't worry — I don't have special powers! The only reason I know you edited your post to delete this question is because I still had a browser tab open from before you made the edit! But I wanted to answer your question anyway, since others may find my overall technique to be very useful.

In a sense, it's a bit off-topic since it's more of a general Raspberry question that could apply to any software. In other words, you're basically asking: "How do I automatically start a program, command or script every time my Raspberry boots up?" Nonetheless, I've customized my answer quite a bit to address your specific "use case" in the warehouse — while also providing enough detail and explanation that anyone can repurpose this general technique to auto-start other applications.

Also, before I continue, I get the sense that for your particular situation, you seem to prefer my slideshow command (fehshow) to my image-viewing command (fehview). Since you're dealing with a single image, it would normally make more sense to point fehview directly to that image. But I'm guessing that maybe the exact name of the file might change from day-to-day, which might explain why you prefer to take a "whatever's in the folder" approach rather than targeting a specific file name.

For that reason, I'm basing this auto-start technique on my fehshow command. In effect, that means when your Raspberry boots up, it will "auto-start a single-image slideshow that constantly refreshes" to satisfy your very specific warehouse scenario. Just realize that you can easily modify the Exec= line, which appears below, to use my fehview command instead.

Finally, I personally tested all of this on a clean copy of Raspbian Desktop to confirm that my method actually works. It worked perfectly! I was especially impressed that in full-screen mode, feh's "--reload" option does not cause any flickering whatsoever when the image refreshes. Instead, the only change my eyes could detect were the pixels that actually changed! So it definitely produces a very slick database-driven "live update" screen for shipment tracking or monitoring stock at a warehouse.

Let me know how everything works out for you!

So here it is — just follow these 2 simple steps to auto-start my fehshow command:

1: CREATE THIS DESKTOP FILE (by running this command line in Terminal):

NOTE #1: In the above example, I'm using a path to a folder named "Warehouse". You will obviously need to change that to suit your needs.

NOTE #2: By invoking "bash -c" in addition to "lxterminal -e" in the above .desktop file, I'm able to issue MULTIPLE commands separated by a semicolon. This trick I discovered — which gets around the annoying single-command limitation of LXTerminal — allows me to place a "mini-script" directly inside a .desktop file — thus avoiding the added complexity of having to point to a separate script file!

NOTE #3: In this particular case, "lxterminal -e" in the above .desktop file is NOT necessary (but it is harmless). That's because feh does not require a visible Terminal window running in the background to provide keyboard control to the user (in full-screen mode, you won't see Terminal anyway). But many other programs do require an active instance of Terminal to provide keyboard control — or to allow for data entry or display. So I wanted to include that element in case other people repurpose my technique for other uses. Nonetheless, if for some reason you don't wish to invoke lxterminal in the above .desktop file, simply get rid of it by changing the Exec= line to this:

Exec=bash -c "sleep 5; fehshow \"/home/pi/Warehouse\""

NOTE #4: The "escaping" I did with the back slashes before the "internal quotes" is necessary to support space characters in the file name or path. It is NOT necessary in this particular case because there are no space characters in the "Warehouse" path I'm using. But I included it anyway because it's harmless and other people may have a need to support space characters in the file name or path. This back slash "escaping" requirement has nothing to do with feh — it's related to the specifics of this particular situation – that we're feeding a quoted list of multiple commands to Bash that also happens to contain internal quoting. And yes, that's 2 double-quotes in a row at the end of the "Exec=" line. But if you don't have any spaces in the file name or path, you can use this simpler syntax — without any internal quotes or back-slash escaping:

Exec=bash -c "sleep 5; fehshow /home/pi/Warehouse"

NOTE #5: The "sleep 5" command is designed to give your system adequate time to "settle down" (after booting) before fehshow is triggered to play the single-image "slideshow". In my testing, I found 5 seconds was quite sufficient — but it's possible that your particular system might require more time in order to avoid problems. For example, in other scenarios, you might need to provide a longer delay to give the Raspberry adequate time to establish an Internet connection.

NOTE #6: X Window (X11) applications — such as LXTerminal — will generally not work if they are started from the /etc/rc.local file (the other common method people use to start commands or scripts upon boot). That's because the X Window System is typically not running at that stage of the boot-up process. Hence my use of the .desktop file approach in this particular case.

NOTE #7: For the "auto-launch during boot" technique to work, Raspbian Desktop needs to be set to "auto login" as user pi, with booting set to the Desktop (not the CLI). These are the operating system's default settings — so you don't need to do anything unless you altered those items. The settings can be checked at Raspberry Menu | Preferences | Raspberry Pi Configuration | System Tab.

NOTE #8: My fehview and fehshow commands are NOT intended to work on the stripped-down "lite" version of Raspbian!

NOTE #9: If you are using the fehshow command instead of fehview for your warehouse purposes, be sure to double-click the "Slideshow Settings" button on the desktop and add "--reload 10" (no quotes) to the feh command line. Feel free to adjust the refresh rate from 10 seconds to whatever you need. The same reload option, of course, can also be used with fehview. To access those settings, double-click the "Image Viewing Settings" button on your desktop.

NOTE #10: To toggle in and out of the full-screen display, press "f". To completely quit the entire application, press "q". For more information on other keyboard controls — or how to change the behavior and settings of fehview or fehshow — please see my main tutorial at the top of this page.

Mike: Hi. I wanted to let you know what happened at the genealogical society in regard to your solution to sorting files in Windows fashion on the raspberry. First, we lost our local tech support guy who originally set up the raspberry devices. Then several problems occurred with the raspberries as there were first set up. For example, the raspberries connect to a network using a username and password but the network administrator changed the username and password and suddenly the raspberries were useless since they could not access our data server. Everyone got discouraged and the Board discussed removing the devices and replacing them with Windows pc's.

Well, I decided to jump in with both feet and was able (with the help of this forum and internet) to get the raspberries working again and even enhanced them somewhat to make them easier to use for our researchers. Then I decided to try to implement your sorting solution. And it worked beautifully!

Now everyone is happy and we are moving forward. Thanks, again, for all your help.

Then I decided to try to implement your sorting solution. And it worked beautifully!

Now everyone is happy and we are moving forward. Thanks, again, for all your help.

mark
Northeast PA Genealogical Society

Excellent!

I'm glad my image-viewing solution is working well for your organization.

Just a brief note of explanation for others:

My solution features automatic "sorting" of images in natural, human-friendly order. For example, 1.jpg will always appear before 10.jpg — instead of 10.jpg appearing before 1.jpg. This may seem like an obvious way to do things, but many Linux applications do it backwards (such as GPicView).

It's important to realize, however, that my image-viewing solution does not actively "sort" or rename the files themselves. It's an entirely passive process that does not alter or tamper with the files in any way. It only affects display order, which is exactly what the genealogical society wanted!

For those interested in active file sorting — the kind that actually changes file names — check out my file sorting tutorial in the General Programming room.