Is the Pi really slow at decoding JPEGs?

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

Ah, it appears hardware JPEG decode is limited to 2048x2048 pixels. Guide here if you want to try:

Theo

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?

I've been using BatchFSI on RISC OS for many years to bulk process the images from our digital cameras down to a size suitable for the web, and latterly for my wife's Facebook pages [*]. I checked and found it today at:

In my case it is set up to process large source images down to eg: 1024x768 or 1280x1024, with the JPEG quality set at 75%, and the picture aspect locked. Smaller images stay the same size.

To use it you simply point it at source and target directories and let it get on with it.

The ChangeFSI program which BatchFSI uses produces astoundingly good picture quality - far and away better than I've seen elsewhere. At those sizes SwiftJPEG displays them faster than I can click the arrow keys.

All the best,

Iain

[*] I'd noticed that, if you upload a very large picture file to Facebook, they will automatically shrink the image with relatively poor results. Pre-processing them gets round this.

'Things have a way of coming right, if you think about them'

- H A Walker, SR

'Issue' is the word used when people don't wish to admit there's a problem.

--

Iain Logan, Langholm, Dumfriesshire

That's still painfully slow if you're browsing through lots of images. Apart from anything else it makes it very difficult to use because you click on something and then wonder if anything is happning so you click again and once that happens you're lost.

--
Chris Green

Which is why others have suggested rescaling the images for just such browsing to a sensible screen size whilst retaining the originals.

But the OP doesn't want to do that - he wants to have his cake /and/ eat it.

He wants to view his originals, presumably of higher definition than his screen, as instantaneously as possible. Which is why I recommended looking at a light-weight OS which might give some speed increase on the RPi.

But if that is /still/ painfully slow, then the answer to the OP's original question:

is "No! Not useable!"

Horses for courses.

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/

Yes, why not! :-)

Yes, that's fine, as I said I just wanted to be sure I wasn't missing something obvious that was slowing down my particular way of viewing the images.

I'll simply (?) set up my laptop (which is fast enough to scale my original images quickly) to display on the TV screen.

I want to be able to do this with the 'master' images if I can so that adding tags, re-orienting etc. will be done on the master images. It's quite likely that this will happen when looking at these images with friends/family etc. as someone will say "ooh, look, that's Fred at Frinton" or whatever and I want to be able to put the information in there and then. Doing it to copies would be pretty pointless.

--
Chris Green

What about using a database? I seem to recall Datapower can store photos, and it makes it easy to add comments etc. It's also likely that it provides the thumbnail function to provide fast viewing.

--
Alan Adams, from Northamptonshire 
alan@adamshome.org.uk 
http://www.nckc.org.uk/

I seem to remember writing Pic_Index for RISC OS to do that sort of thing and more, including keyword searching on the comments.

Not relevant, perhaps, to the OP, but if anyone else is interested:

If I were doing it all again, I'd probably write it in PHP and run it under a server.

There may be a clue there for the OP.

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/

Most programs (like Digikam which is my current favourite) already do use a database to store metadata about the images.

However I am much happier keeping the information in the JPEG files, it's slower for mass manipulation and searching of course but is much more robust - you can't lose the information for an image.

Digikam allows you to keep the image metadata in step with the database which is a 'best of both worlds' approach. However it means that to keep myself sane I really need always to be seeing my 'master' images when I want to change anything.

--
Chris Green

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