• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category Plugins
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Release 3.4
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by iwantanimac - 2006-11-12
Last edited by teru - 2010-11-21

FS#6321 - Universal Image Viewer

This would be a pretty much universal image viewer. Perhaps even to replace the jpeg plugin. bmp support already exists, as there is a plugin for it, but other formats would be good, too.

The plugin should;
- Detect image format before loading (If it cannot be identified by file extension, it should check for header data if it’s not recognised)
- Be able to display the following formats:

    1. Transparency could be an issue, i guess you would just choose what background to have displayed, or not enable the alpha channel. (Not that i know how you would go about this…) - similar for GIFs
    1. Would animated GIFs be possible (As an animation)? Otherwise, allow cycling through frames.
  1. BMP (Already implemented with the BMPviewer plugin with BMP Resize - #5697}
  2. Possibly JPG, replacing the current jpeg plugin (If it’s good enough), or becoming part of the jpeg plugin.

- Resize images (Like the way the jpeg plugin does it, not like BMP Resize, as this looks horrible)
- Cycle through images of ALL compatible formats, and have slideshow function (like JPEG plugin)
- Anything else appropriate (And most of the features already present in the jpeg plugin)

Comments, contributions or anything else would be awesome, as i think this would be excellent for the big 4 image formats to be supported. Hopefully most targets have the processing power to decode these formats quick enough!

Closed by  teru
2010-11-21 14:00
Reason for closing:  Accepted
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

committed in r28626.

aww, it didn’t keep my whitespace… grr… PNG and the next line are related, as are GIF and the line under that.

As i said, if anyone can contribute or help, that’d be great.

I’ve already implemented GIF with  FS#3037  and I saw you commented there… Animation is tough cause you need to keep in the memory every frame
(or changes of frame like the file itself keeps)
but i tried to implement animation in this one…

I highly support this request. I’d like to see PNG support particulary!

Meanwhile Christophe Gouiran wrote a PNG plugin ( FS#9493 ), so the aim of this task should be to merge the JPEG and the PNG plugins to a single image viewer.
BMP decoding support already exists and Michael Ignatiev is working on a BMP viewer. ( FS#10535 ) In my opionion it would be better to focus on a universal image viewer.

The aim should be that Rockbox also supports PNG album art, but this is a another task…

teru commented on 2009-12-23 08:03

this patch merges user intereface part of code in JPEG Viewer and PNG Viewer. note that they are still separate plugin.
this aims for:
* make it simpler to add new image viewer (bmp, gif …) with same ui as JPEG.
* get rid of maintaining two almost same code.
* probably first step to merge these viewer plugins to one image viewer plugin.

Nice! Have you thought about putting it into the pluginlib instead?

Also, there’s a image viewer with could potentially use it: ppmviewer.

It’s probably a good idea to keep the plugins separate, otherwise you need black magic for managing the memory.

teru: Can you please also update the manual accordingly?

teru commented on 2009-12-23 08:53

I haven’t thought that idea. but I think this implementation is not likely to suit for that.
I made this so that files in jpeg/ and png/ look more or less a “image codec” and put all stuff needed for a plugin to ui code.
yeah, ppmviewer could use this.

I don’t think i changed something that needs to change manual.

I haven’t thought that idea. but I think this implementation is not likely to suit for that.

Can you explain that? Isn’t the UI part API which the plugins call? That perfectly suits to the pluginlib.

teru commented on 2009-12-23 09:27

below is abstract of function calls.
i moved functions plugin_start, load_and_show, scroll_bmp to imageviewer_ui.c as they are common and left load_image, get_image, draw_image_part in jpeg.c/png.c as they are specific.
so, imageviewer_ui.c is core part and it calls functions in jpeg/png when load, decode/resize, or display image.

plugin_start() {
/* initialize file list and get plugin buffer etc. */
/* deinitialize. */
} load_and_show() {
load_image() /* load file from disk */
while() {
get_image() /* decode/resize image to display */
draw_image_part() /* display image */
scroll_bmp() /* handle button */

teru commented on 2010-01-15 14:35

Update patch.
* moved jpeg/ directory and png/ directory to under imageviewer/ directory.
I’m thinking to merge the two plugins to single image viewer later.

before apply the patch, it is needed to create apps/plugins/imageviewer/ direcotry and move both apps/plugins/jpeg/ and apps/plugins/png/ under it manually.
e.g. (if using svn):
$ svn mkdir apps/plugins/imageviewer
$ svn mv apps/plugins/jpeg/ apps/plugins/png/ apps/plugins/imageviewer

teru commented on 2010-01-21 02:59

Here is my work for universal image viewer. this is test version and may contain problems to freeze or crash the player or might not work at all especially on lowmem targets.
this includes adapted version of  FS#10535 .
tested on gigabeat X.
this uses loadable image decoder borrowing code from lib/overlay.c
with this patch, some files will be created - imageviewer.rock, imageviewer_bmp.ovl, imageviewer_jpeg.ovl, imageviewer_png.ovl (only for color targets still).
it should work like following.
when a supported image file (bmp, jpeg, or png) is played, imageviewer.rock is launched as usual.
create list of names of supported image in current directory. this is same as current jpeg/png viewer.
then the plugin determine type of the image (one of bmp, jpeg, png) by it’s extension and load appropriate decoder (imageviewer_X.ovl where X is bmp, jpeg, or png).
- the decoder is loaded at the end of the plugin buffer.
the decoder will load/decode or resize/display the image on demand.
when the image is changed, another decoder is loaded if needed (e.g. when chaged to b.jpeg from a.bmp).

on the simulator, all decoders are linked to imageviewer.rock and loading decoder at runtime is not done.

some random thoughts:
* need to check how much memory is used for imageviewer.rock, grey buffer and decoder, and ensure they don’t conflict each other.
* and maybe compare to current jpeg.rock/png.rock.
* consider a way to exclude png entry from viewers.config for non color targets.
- maybe add “png,imageviewer_png” instead of “png,imageviewer” and strip _png while buildzip?
* no idea.

teru commented on 2010-02-19 15:39

synced to r24774.

teru commented on 2010-05-17 14:39


Edit: replace the patch. don’t use previous imageviewer.3.patch.

teru commented on 2010-08-27 13:40


this works to me but i haven’t solved 1 issue yet - png entry is included to viewers.config even for non color targets while png is not supported yet.

teru commented on 2010-09-21 13:21

Update patch.
use lc_open to load decoder and do loading decoder on the simulator.

teru commented on 2010-09-26 14:59

update patch.
*preprocess viewers.config to exclude unsupported types.
*remove unneeded rb→cpucache_invalidate(); (thanks to kugel).

teru commented on 2010-11-01 14:47


teru commented on 2010-11-01 15:28

fixed typo…

teru commented on 2010-11-02 13:32

third try.. i should have tested before apploding patch.
i tested this and worked on gigabeat x30 and ipodmini1g.

Works fine on fuze v2

teru commented on 2010-11-10 11:36

Thank you for testing.


Available keyboard shortcuts


Task Details

Task Editing