Is the Pi really slow at decoding JPEGs?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I was going to use my Pi to view my photo collection on the TV but it
seems it's simply too slow to be usable.

My photo collection is nearly all JPEGs with file sizes between about
2Mb and 10Mb.  I've tried two or three applications to view these and
they take 20 to 30 seconds to decode and show each image.  Is this
just the way it is (i.e. not usable) or are there programs out there
that can decode JPEGs faster?

--  
Chris Green


Re: Is the Pi really slow at decoding JPEGs?
On Mon, 09 Feb 2015 22:08:56 +0000, cl wrote:

Quoted text here. Click to load it

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.
We've slightly trimmed the long signature. Click to see the full one.
Re: Is the Pi really slow at decoding JPEGs?
On Mon, 09 Feb 2015 22:23:15 +0000, alister wrote:

Quoted text here. Click to load it

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

Re: Is the Pi really slow at decoding JPEGs?
Quoted text here. Click to load it

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]

Re: Is the Pi really slow at decoding JPEGs?
On 2/9/2015 14:37, Andrew Gabriel wrote:
Quoted text here. Click to load it

I think that is the hold up.  I've been playing around with an image  
viewing program and most of the time is spent loading the image file,  
not rendering it.  Since he's sending his file through a network  
connection too that is only going to make it slower.

knute...


Re: Is the Pi really slow at decoding JPEGs?
On 09/02/15 22:23, alister wrote:
Quoted text here. Click to load it
???

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



Re: Is the Pi really slow at decoding JPEGs?
On Tue, 10 Feb 2015 06:17:06 +0000, Dom wrote:

Quoted text here. Click to load it

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



--  
<Ze0> so, how's everything in the world of Quack?
<LordHavoc> just ducky
We've slightly trimmed the long signature. Click to see the full one.
Re: Is the Pi really slow at decoding JPEGs?
On 2015-02-10 09:36, alister wrote:
Quoted text here. Click to load it

debian does not use it, raspiab does.

--  
--


Re: Is the Pi really slow at decoding JPEGs?
Quoted text here. Click to load it
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.

Quoted text here. Click to load it
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


Re: Is the Pi really slow at decoding JPEGs?
On Tue, 10 Feb 2015 10:29:44 +0000, cl wrote:

Quoted text here. Click to load it

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.

Re: Is the Pi really slow at decoding JPEGs?
Quoted text here. Click to load it

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

--  
Chris Green


Re: Is the Pi really slow at decoding JPEGs?
Quoted text here. Click to load it

I tried the exact setup you have, with a NFS mounted drive over a gigabit/100m
switch; and viewed 349 files with xzgv. The screen is a DVI 1024x1600 one
with adapter, and I had xzgv resize everything to the max resolution, which
minus borders etc is around 980x1570; but keeping the aspect ratios. That
took an average of 0.8 seconds per image (I just held the spacebar down to
have it display all the pictures in sequence). That took 4:14, including 6-8
seconds of maximising the window at the start. time said I used 87 seconds
cpu, 14 system and 52 in wait state (for nfs), the rest idle (waiting for
keyboard input). This is on an 'old' B, running raspbian at 900 Mhz.

The average file size is 108 kilobytes, optimized images from a website.

Files of a few megabytes takes substantially longer, especially when
resizing. I tested with a 4096x3072 image at 17 megabytes, that took 22
seconds to rescale and display. Around 40% of this time was waiting for
the nfs disk.

Not too bad. My old pentium machine wouldn't have been able to do anything
of this.

-- mrr



Re: Is the Pi really slow at decoding JPEGs?

Quoted text here. Click to load it

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".

Re: Is the Pi really slow at decoding JPEGs?

Quoted text here. Click to load it

The Pi does have hardware floating point.

3 years ago with the original Debian, it still had the hardware FP,
but it wasn't being used however a month later with Raspbian it was
being used and has been fully in-use since then.

Gordon

Re: Is the Pi really slow at decoding JPEGs?
On Mon, 09 Feb 2015 22:08:56 +0000, cl wrote:

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Is the Pi really slow at decoding JPEGs?
Quoted text here. Click to load it
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


Re: Is the Pi really slow at decoding JPEGs?
Quoted text here. Click to load it

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




Re: Is the Pi really slow at decoding JPEGs?
On Tue, 10 Feb 2015 11:26:24 +0000, cl wrote:

Quoted text here. Click to load it
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
We've slightly trimmed the long signature. Click to see the full one.
Re: Is the Pi really slow at decoding JPEGs?
Quoted text here. Click to load it
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).


Quoted text here. Click to load it
They're already in the directories where I want to view them.


Quoted text here. Click to load it
Also done.


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


Quoted text here. Click to load it
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


Re: Is the Pi really slow at decoding JPEGs?
On Tue, 10 Feb 2015 13:23:58 +0000, cl wrote:

Quoted text here. Click to load it
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.
  
Quoted text here. Click to load it
I don't remember you saying exactly that, only that it was too slow to  
generate thumbnails.

Quoted text here. Click to load it
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
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline