This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#6321 - Universal Image Viewer
Attached to Project:
Rockbox
Opened by Geoff Stokes (iwantanimac) - Sunday, 12 November 2006, 15:09 GMT+2
Last edited by Teruaki Kawashima (teru) - Sunday, 21 November 2010, 15:00 GMT+2
Opened by Geoff Stokes (iwantanimac) - Sunday, 12 November 2006, 15:09 GMT+2
Last edited by Teruaki Kawashima (teru) - Sunday, 21 November 2010, 15:00 GMT+2
|
DetailsThis 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: - PNG [http://www.libpng.org/pub/png/png-sitemap.html#programming] - 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 - GIF [http://www.cs.cornell.edu/dali/api/gif-c.html - I think that's ok] - Would animated GIFs be possible (As an animation)? Otherwise, allow cycling through frames. - BMP (Already implemented with the BMPviewer plugin with BMP Resize - #5697} - 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! |
This task depends upon
Closed by Teruaki Kawashima (teru)
Sunday, 21 November 2010, 15:00 GMT+2
Reason for closing: Accepted
Additional comments about closing: committed in r28626.
Sunday, 21 November 2010, 15:00 GMT+2
Reason for closing: Accepted
Additional comments about closing: committed in r28626.
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.
FS#3037and 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...
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...
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.
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.
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.
tomers:
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.
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. */
__while()
____load_and_show()
__/* 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 */
__}
}
* 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
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.
Edit: replace the patch. don't use previous imageviewer.3.patch.
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.
use lc_open to load decoder and do loading decoder on the simulator.
*preprocess viewers.config to exclude unsupported types.
*remove unneeded rb->cpucache_invalidate(); (thanks to kugel).
i tested this and worked on gigabeat x30 and ipodmini1g.