Release Pandora Image Viewer


_wb_

Microbe
Staff member
Joined
Apr 5, 2012
Messages
5,390
Age
42
Location
Brussels, Belgium
The first release on the repo will be later (maybe next week or so), but I'll already start a thread about this to let you know what I'm currently working on, and maybe already get some early feedback (like suggestions for names).

Edit: repo link: http://repo.openpandora.org/?page=detail&app=piv.wb

I want to use my Pandora to view pictures taken with my digital camera. The Pandora is quite nice for this, because I can just insert the SD card from my camera in my Pandora.

However, the default image viewer (ristretto) is quite slow, and I don't think the other viewers on the repo are much faster. My camera makes 10 megapixel JPEG files, about 5MB each. On my 1GHz unit, using ristretto, it takes about 2.5 seconds per image to load it and show it scaled to fit the screen. That is not an acceptable speed. Also, zooming in and out is not practical at all in ristretto.

So I decided to make something better, tailored to the Pandora. I'll call it "Pandora Image Viewer" for now, unless someone has a better name for it - suggestions are welcome.

Edit: decided to keep the name, "Pandora Image Viewer" or "PIV"

Advantages:

  • It's fast. About 5 times faster than ristretto (less than 0.5 second per image when viewing those 10MP JPEG files).
  • Full 24-bit color. It uses notaz' SDL so you don't get 16-bit color like in all other image viewers.
  • Nice zooming. Press X/Y to zoom in/out, use the nubs to navigate (left nub for fast movement, right nub for precision movement)
  • It does a lot of preloading, so in practice, it feels extremely snappy (no delay at all when pressing the next/previous button)

Disadvantages or limitations:

  • Only supports full-screen, not windowed. In my opinion, that's the only thing you need anyway, especially on a small screen like that of the Pandora.
  • No advanced features at all. Just "next", "previous", "zoom in/out", "start/stop slideshow" and that's it. No image editing stuff. No thumbnails. No photo collection management stuff. Maybe I'll add more features when someone requests them or when I feel the need, but this is not going to be anything advanced. Just a simple image viewer. Let me know what you think it should be able to do. Edit: it is starting to get more features :)
  • Very minimal interface: at the moment it's just a zenity dialog that lets you select a folder, and then it will show all images in that folder.
  • It will eat all your RAM - I could change that, but I prefer to preload as much as possible, to make everything as snappy as possible. It does not need a lot of RAM though, so if you're low on memory, it will just do less preloading.
  • It only uses the CPU - not the GPU or the DSP. Probably it could be even faster if those would be used effectively. But unless you want to view extremely huge images, I don't think it's worth the effort.

So how did I get it 5 times faster than ristretto?

First of all, it uses libjpeg-turbo, which uses NEON to speed up the decoding of JPEG files. That already helps quite a bit - by the way, I would recommend to use this in the default firmware too.

Next, it loads large JPEG at 1/4 or 1/2 resolution at first (until you start zooming in), which means decoding is faster and there's less downscaling effort needed afterwards.

Then, in order to fit the image to the screen, it uses the hardware scaler to downscale (or upscale, in case you're zooming in a lot) the image.

For example: say you have a 4800x3600 JPEG file (17.2 MP). At first, it gets loaded at 1/4 resolution, which gives us a 1200x900 surface. The hardware scaler then downscales it from that. If you zoom in, higher res decodings are done and we simply adjust the size of the screen to the desired zoom level. For example, if you zoom in to 4 times the original resolution, I simply set the screen size to 200x120 and blit parts of the 4800x3600 image to that.

I make sure that the JPEG decoding goes straight to the right surface format (XBGR) - this is something that libjpeg-turbo supports, but the default libjpeg doesn't, meaning that after decoding the JPEG file, you still need to convert the resulting surface to the screen format.

The above steps are enough to speed up things by a factor of 5. Then by preloading as much as possible, things become really very snappy.
 
Last edited by a moderator:
Sounds good!

What is this libjpeg-turbo? standard libjpeg but coded with NEON? Maybe I can use that lib to speed some game that are slow with lots of jpeg?
 
That's quite impressive. I wonder if more of those arm optimized libs exist.


Also good use of the hw scaler feature. Almost as if the omap guys had something like this in mind when adding that feature.
 
Sounds good!

What is this libjpeg-turbo? standard libjpeg but coded with NEON? Maybe I can use that lib to speed some game that are slow with lots of jpeg?
Exactly. See http://libjpeg-turbo.virtualgl.org/

I think it would probably be a good idea to replace the default libjpeg with that one - it's completely compatible.

Now the next tool we need is a RAW file to PNG or JPEG converter :)
I have a crappy camera, it does not produce RAW files, so I didn't think about that. But libjpeg-turbo is also fast at encoding, so it could be useful for that too.

I'm also putting the latest version of libpng in this, it also has NEON optimizations now.
 
I have a crappy camera, it does not produce RAW files, so I didn't think about that. But libjpeg-turbo is also fast at encoding, so it could be useful for that too.
My camera only produces RAW pictures :) I mean, I only want to produce raw pictures for conservation, so having a portable RAW to PNG converter at hand would be great, actually, when traveling.

One request, if you could incude a sharing function with your viewer that would be absolutely great. Like "share via email" or something like that. if you could pass the picture as a parameter to launch clawsmail for example it would be excellent.
 
How does the UFRaw GIMP plugin perform on the Pandora?  I know it's kind of laggy dragging the slider on my netbook, but I make do if I'm on the road and want to release some photos.  I guess it also doesn't play nice with the screen resolution, as it compresses some of the graphs beyond readability on this 1024x600 netbook screen.

To be honest, I don't consider RAW processing to be part of the image viewing workflow.  I want to process each raw file to jpeg just once per version of the photo I produce (normally just once in total then), and don't want to have to remember the conversion parameters

You could also use Dave Coffin's dcraw - should be an easy port, but personally I have only ever used that to provide a quick preview of a raw file using default or averaging parameters, as entering all the parameters I'd need without an image preview on the command line is not my idea of fun.  Perhaps an image viewer could invoke dcraw with some sensible defaults to at least get you a view on a RAW file, though it would slow things up a lot I suspect.

There's also the issue that every so often each camera manufacturer releases a new camera and apparently deliberately breaks the raw file format.  Dcraw gets updated quite frequently to handle the newer models, so adding a build of it to your viewer adds something of a maintenance burden.
 
Sounds good ... a fast image viewer that makes good use of the Pandora controls would be great!

How about "Pandorama" as name? Allthough it might get confused with "Panorama" ... "Pandiviewer"?

Two things I would find extremely usefull in an image-viewer:

1) rotate the image left or right (actually a must in my opinion)

2) a thumbnail view. Maybe press select (or zoom out once more when the image is already fitting the screen), and you get a bunch of thumbnails you can browse through with the d-Pad and select one.

Browsing may become slow, especially when the images are large of course ... and I have no idea how hard it would be in general to implement this, I fear it can easily become as much work as writing an entire viewer from scratch (because it essentially would be a viewer within the viewer including a GUI).
 
btw, _wb_, the faster picture viewer for Pandora is geeqie (the version i ported last 1.23 i think) and you could check how fast it is versus your soft. Geequie is significantly faster than all other image viewers.
 
I just tried geeqie. It's a bit faster than ristretto, but still much slower than my viewer. Here are my (very crude) benchmark results. The test was to view 10 JPEG files (scaled to fit the pandora screen), each about 5 MB in file size and 10 megapixels in resolution.

- gthumb segfaults when I try to view the files, probably it's my fault, I should try on a virgin firmware

- ristretto takes about 26 seconds (2.6 second per image)

- geeqie takes about 23 seconds (2.3 second per image)

- GQview takes about 22 seconds (2.2 second per image), but its scaling looks a bit jagged

- gPicView takes about 21 seconds (2.1 second per image)

- my viewer takes about 4.7 seconds (0.5 second per image)
 
Interesting project in itself, and on top of that has certainly sparked my interested in looking at NEON optimized versions of libpng (I wonder if there are any other common libraries with decent NEON optimizations, zlib for example).
 
Exactly. See http://libjpeg-turbo.virtualgl.org/

I think it would probably be a good idea to replace the default libjpeg with that one - it's completely compatible.
Are you 100% sure? If they claim something on their site it's not necessarily true, they might have bugs and not even know it.

Replacing libjpeg in old OE build is risky, it would most likely cause many packages to be rebuilt, and that may fail due to various reasons (as it's often the case with OE), like because host tools changed when ED updated Debian, or source of some package is no longer available, and that would mean we lose ability to build firmware updates. Many updated packages may also cause opkg to fail again like it had on one recent update, which left users without wifi.
 
Please add file associations.

So that when I double click in the file manager your PND will be able to start up directly.

It's pretty important I think.
 
Exactly. See http://libjpeg-turbo.virtualgl.org/

I think it would probably be a good idea to replace the default libjpeg with that one - it's completely compatible.
Are you 100% sure? If they claim something on their site it's not necessarily true, they might have bugs and not even know it.

Replacing libjpeg in old OE build is risky, it would most likely cause many packages to be rebuilt, and that may fail due to various reasons (as it's often the case with OE), like because host tools changed when ED updated Debian, or source of some package is no longer available, and that would mean we lose ability to build firmware updates. Many updated packages may also cause opkg to fail again like it had on one recent update, which left users without wifi.
Well, at least I did not have to recompile SDL_image to make it work with libjpeg-turbo, so it must be quite compatible. In the end I did recompile SDL_image anyway for another reason.

The NEON-optimized libpng is not binary compatible with the old one though.
 
How fast is it compared to Viewnoir? Also, does it support other image types than JPG/JPEG? If so, which ones?
 
Last edited by a moderator:
I didn't know about Viewnior, but I just tried it. It took about 20 seconds for my little benchmark, which makes it the best viewer currently available on the repo afaik. But my viewer is still 4 times faster ;)

My viewer supports everything SDL_Image supports: BMP, GIF, JPEG, LBM, PCX, PNG, PNM, TGA, TIFF, WEBP, XCF, XPM, XV.

It is however particularly optimized for JPEG. It'll probably still be faster than the other viewers for those other file formats, but not by such a big factor.
 
Back
Top