This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#11641 - extend and fix png support in imageviewer plugin
Attached to Project:
Rockbox
Opened by Marcin Bukat (MarcinBukat) - Friday, 24 September 2010, 09:28 GMT+2
Last edited by Marcin Bukat (MarcinBukat) - Sunday, 31 October 2010, 13:44 GMT+2
Opened by Marcin Bukat (MarcinBukat) - Friday, 24 September 2010, 09:28 GMT+2
Last edited by Marcin Bukat (MarcinBukat) - Sunday, 31 October 2010, 13:44 GMT+2
|
Details1) Code cleanups - move PNG color types to defines (instead of magic numbers
used directly). Change arithmetics in a few palces to use shifts instead of muls. 2) Comment out tIMe chunk processing as we do not check nor set timestamp of png file. 3) Rework LodePNG_convert() to output pixels in rb specific format (greylib or native). 4) Enable support for greyscale targets. 5) Change optimization to -Os (from -O3) This was tested in the sim *only* so tests on different real hardware is welcome. The most interesting is mrobe500 (as it has different native pixelformat then any other color target) and greyscale targets |
This task depends upon
Closed by Marcin Bukat (MarcinBukat)
Sunday, 31 October 2010, 13:44 GMT+2
Reason for closing: Accepted
Additional comments about closing: commited as r28413
Sunday, 31 October 2010, 13:44 GMT+2
Reason for closing: Accepted
Additional comments about closing: commited as r28413
Other minor optimizations.
replace info->width to STRIDE(SCREEN_MAIN, info->width, info->height) in for rb->lcd_bitmap_part at line 1496 in png.c (see imageviewer/bmp/bmp.c).
also, smooth_resize_bitmap needs to be fixed for mrobe500.
1) Add support for true transparency
2) Add support for simple transparency (tRNS chunk)
3) Add support for background color (bKGD chunk)
4) Masive code refactoring to separate decoder from plugin specific stuff
5) Various cleanups
6) Fix draw_image_part() to use STRIDE macro (proposed by teru).
Missing: image scaling is broken on mrobe500
but i don't have a device to test and don't know internals at all, so i don't know if this is proper.
btw, calculation of decoder->native_img_size seems slightly wrong.
IIUC, it should be (decoder->infoPng.width*decoder->infoPng.height*FB_DATA_SZ + decoder->infoPng.width*sizeof(struct uint8_rgb)) for color targets and (decoder->infoPng.width*decoder->infoPng.height + decoder->infoPng.width) for the target using greylib.
1) revert to byte fetch and shift processing of fields in png file (pointer magic from v2 makes strange thing on arms which can't do unaligned fetches)
2) correct calculation of native_img_size
3) use fixed bitmap scalers (fixes were commited as r28185 and r28187)
* Other minor changes in decompressor
* Other minor changes in decompressor
The patch works on both tested targets, the only thing I'm wondering about is why I sometimes get "file too large" and sometimes "out of memory" on larger files but I could imagine that it has to do with compressed and decompressed size?
Another thing I noticed is that the Archos versionl doesn't do aspect ratio correction like e.g. the bmp viewer does and I noticed when comparing with a square file (200x200) that the bmp player states "decoding 200x160" (so corrected) and the png viewer "decoding 200x200", so to me it looks like the difference is already at the loading step (?). Fixing this is not very important but would be nice :)
'out of memory' comes from decompressor or decoder.
There are (at least) two points where 'out of memory' may popup:
1) PNG file has lots of additional chunks and there is no place in buffer to copy raw compressed stream
2)Converting decoded PNG image to desired pixelformat (greylib or native) needs to hold both decoded image, converted image and one line big temp buffor. Later on decoded image and temp buffor are discarded and free space is used as scaler buffor. In theory it is possible to reduce memory needed in this step.
'out of memory' comes from decompressor or decoder.
There are (at least) two points where 'out of memory' may popup:
1) PNG file has lots of additional chunks and there is no place in buffer to copy raw compressed stream
2)Converting decoded PNG image to desired pixelformat (greylib or native) needs to hold both decoded image, converted image and one line big temp buffor. Later on decoded image and temp buffor are discarded and free space is used as scaler buffor. In theory it is possible to reduce memory needed in this step.