Is the Pi really slow at decoding JPEGs?

a 1080p TV is less than a 2 mega pixel display (about 1-1.5) if you jpeg file is taking up 10MB it needs considerable rescaling before it is displayed (even 2mb file size is quite large) you will probably find that resizing the images before copying them to the Pi will help considerably.

remember the pi does not have a hardware floating point unit.

--
If it is a Miracle, any sort of evidence will answer, but if it is a Fact, 
proof is necessary. 
		-- Samuel Clemens

When saving the jpeg, you can also reduce 'quality' parameter quite a bit before you can see any difference - 60% is generally quite adequate.

Also, how quickly can you copy one of the files from its media (an uncached one)? Just wondering if that might be limiting the speed.

--
Andrew Gabriel 
[email address is not usable -- followup in the newsgroup]

I ran into a similar problem on a rather faster system (desktop, dual core 3.2 GHz Athlon).

I decided that what I wanted was to throw my picture collection into a directory structure which would be equivalent to a picture topic index that could be clicked through using a standard web browser. This much is dead easy to do: run Apache on the box that holds your pictures and set the permissions so that a web browser can be used to navigate through the directory structure and show the snaps you wanted to see.

However, I decided that: (1) unmodified directory names are ugly and (2) I wanted to see a list of clickable thumbnails instead of a list of picture names.

So I wrote a fairly simple recursive PHP script that made directory and filenames more readable (Capitalise 1st char, replace underscores with spaces) and generated thumbnails on the fly from image files by generating an image.html file that the web browser will automatically select instead of parsing the directory. It worked: the readable directory and filenames were fine, but thumbnail generation took forever: it used ImageMagik to generate the thumbnails. ImagreMagik is great, but was never intended to make thumbnails from tens or hundreds of images while the punter waits to see the result.

Next attempt: I added an overnight PHP cronjob that walked the directory structure and, for every image file that didn't have an up to date thumbnail in a .hidden directory, added one and removed thumbnails whose image files no longer existed. The index.html file was the same as before except that it now displayed thumbnails under the filenames of image files so the viewer could click either to see the fullsize image. This was fine except that it was still rather slow to process a new directory full of images.

The final state of play is that the slow overnight PHP script has been replaced with a much faster Java equivalent using library image transforms. Its usual overnight scan doesn't find anything that needs doing and so completes in 3-4 seconds. If I've dropped a new set of pics into a directory, I know that thumbnails will be created overnight at the rate of several per second.

This has remained stable and unmodified for the last 2-3 years: it 'just runs'.

I see no reason why a similar wheeze shouldn't run on a Pi: both Apache and PHP are available as packages. I got perfectly acceptable response speeds running Apache on an 886 MHz '486 box with 512 MB RAM as a private, in-house web server. Put it on a Pi 2B and it should fly.

HTH

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |

???

pi@raspberrypi ~ $ dpkg --print-architecture armhf ^^ (hf = Hard Float)

I stand corrected Was it just early that early releases of OS were unable to use it?

--
 so, how's everything in the world of Quack? 
 just ducky 
 excellent, fried duck is mighty fine tasty.

debian does not use it, raspiab does.

--
--

I got a lcd screen (another than in a previous thread)

that is 320x240 . I have used it for showing jpg's and it is quite fast in doing that, ~1 sec for loading each image.

But of course, it looks bad at that resolution.

So, reading the file from disk/sd-card is not the problem

I realise making them smaller would make things faster but it's not a practical approach. I have something like 28000 images and these are my 'master' images, I don't want to keep a parallel 28000 smaller images.

I'm not complaining as such, just wondering if I am getting the expected performance, in which case I'll need to use another approach.

--
Chris Green

Yes, OK, it would work, but it's a lot of effort just for a way to view images that are already sorted, tagged, etc. in the way I want them.

I'm not after a web view of the images, I'm just after a way to show them to family, visitors, etc. when they say "do you remember that holiday in Corsica" or "have you got any pictures of our old house".

For my own use I use my (fairly fast) desktop machine, there I can whizz around the pictures using Digikam and access is near enough instant. I'm just after a fast, handy, viewer for somewhere else on the home LAN.

--
Chris Green

It does. I remember that when the first Raspberry Pi appeared back in

2012, the first Debian port had a soft-float kernel, so maybe you were thinking of that. A hard-float version was made available within a couple of months, and I think it was included in the first version of "Raspbian".

Actually, that's what the system I described was designed to do and thats exactly what the third iteration does. Here is exactly what I do to all a new set of pictures:

1) Create a appropriately named directory in the logical part of the structure, e.g. the pics from a Pennines soaring holiday last year might go in a new directory named 'eden_soaring_2014' in the already existing 'travel/uk' directories 2) The pics get dumped in the directory where they can be viewed.

3) The real duds thrown out and any that could do with cropping, brightening, etc are tweaked with GIMP. Then I'm done.

4) The following night's run sets up thumbnails. Job done.

The next morning Firefox will show a page headed "Eden soaring 2014" followed by the thumbnails. Click any thumbnail to see further details. And, because the thumbnails are pre-built, the contents of a directory holding hundreds of pictures still loads in a second or two and scrolls as fast as you can drag the cursor.

Another nice thing about this way of doing it is that any other related files can be put into the same directory structure without upsetting the directory generator. The one special tweak is that it will not try to make thumbnails for the contents of any directory that contains an 'index.html' file - I'll create one of I want to build a page containing both images and text but that is never needed if all the directory contains is a set of snaps.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |

I don't want to do this step. My pictures are *already* organised in a 1990s/1991/05/12 type of hierarchy (many have descriptive text after the bare month and day numbers).

They're already in the directories where I want to view them.

Also done.

?? I don't really understand this, the whole problem is that the Pi is too slow to display the full-size picture.

Scrolling around the thumbnails isn't the issue and, anyway, have you ever tried running Firefox on a Raspberry Pi - don't bother! :-)

--
Chris Green

The Pi GPU can do hardware JPEG decoding via the OpenMAX API. However I don't know which if any apps use OpenMAX.

Theo

So, if you want to try this approach, point the overnight run at the hierarchy you already have.

I used to use a photo import app that set up that sort of year/month/day directory structure but I never liked it because I simply don't remember when I might have taken a set of photos: hence my personally built subject-based directory structure, but obviously ymmv.

I don't remember you saying exactly that, only that it was too slow to generate thumbnails.

No, and I wouldn't try, but running Apache and the thumbnail generator on a B+ or later should be OK: My photo management and display system was developed on an 886 mHz P4 system with 512MB RAM and ran at a decent speed there. It only got moved to bigger iron when a new version of Fedora was released with an installer that required at least 1 GB of RAM.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |

I don't have any photos quite that big, but using RISC OS and the application SwiftJPEG, a 2Mb+ JPEG takes about a second (very approximately) to resize and display to fill a screen window. This is from a USB hard disc.

If you wish to try it for yourself, RISC OS is available on NOOBS, and the SwiftJPEG application is at:

A RPi might make a useful photo-viewer!

Hope this helps, John

--
John Williams, now back in the UK - no attachments to these addresses! 
Non-RISC OS posters change user to johnrwilliams or put 'risc' in subject! 
Who is John Williams? http://petit.four.free.fr/picindex/author/

I assume you copy the files to some media (SD, flash drive, etc.) a relatively simple script could resize them from the originals as they are copied.

No, they're not copied, I just NFS mount them.

--
Chris Green

I use both qiv and xzgv a lot for this, they are fast command-line interface tools. "find . -name '*.[jpgJPG][inpINP]*[fgFG]' -print0 | xargs -0 xzgv --" tends to work very nicely finding gif/jpg/png files in the tree below it. Runs to display images fast.

-- mrr