Accessing PNG viewer libs from another plugin

[gbl08ma]

I'm a newbie to developing for Rockbox, but I already use Rockbox since some months ago... I've just set up a development environment on an ubuntu virtual machine, already compiled and applied some patches, and I'm thinking on writing a plugin.
As per the feature idea on http://forums.rockbox.org/index.php?topic=18204.0 (read the latest posts), I'm (trying to) developing a map viewer plugins which will use map images downloaded by an open source program called GMapCatcher. My idea is that the images (which all have 256x256 of width/height and are in PNG format) are put one next to other in order to render a complete map, just like GMapCathcer does. The map image files would need to be copied from a certain folder on the PC to a certain folder on the DAP.

The images are organized in folders in series, according to their zoom level and coordinates. This work is all done by GMapCtcher, so the plugin would only need to render the images in the correct position, go to X,Y corrdinates a user specifies, go to saved locations, and such. In the future I would like to add route calculation but perhaps this last feature is just dreaming too high

My question is, as the images are in PNG format (and converting millions of images into BMP isn't an easy thing to do), and as Rockbox doesn't support drawing of PNG images out of the box, is there any way to access the libraries included in the PNG viewer to decode the images and show them on the screen? Something that would allow me to create a PNG-based graphics API for the PNG format, for use on the maps plugin. The idea is NOT to add PNG support to Rockbox (so don't start dreaming, as it is impossible due to hardware/speed limitations), but instead create/use something that will only be used on the maps plugin.

Anticipated thanks,
Gabriel

PS: If someone wants to help me developing,  you're greatly welcome, just inform me and I'll start releasing patches to flyspray. However, what I have currently is just a code stub with a menu skeleton, and I don't think there would be a good reason to post a patch right now.

[saratoga]

Easiest way would be to compile the PNG viewer into your plugin by including it in your makefile (or SOURCES file).  If other plugins need to use it, we could also add it to the plugin API.

[gbl08ma]

I suppose I only need to add ../imageviewer/png/[some source file] on the SOURCES file of my plugin, correct (my plugin is in a separate folder)? After that, I can call the PNG decoding functions out of my maps plugin, correct?

I'm going to try it now, when I open my development environment virtual machine.
Thanks for the help.

EDIT: I just started looking further into the PNG code now, it seems that, apart from the filename, it also needs a image_info struct to load_and_show the image. So, adding PNG support to the API would be useful if it was made to happen like with BMP (we only need to provide the filename and a x,y coordinate to position the image onscreen).

EDIT 2:
I have been "investigating" and just realized that using directly the libs from the PNG viewer would be both difficult and not a good coding practice (in my opinion). Including PNG support on the API (just like what happened with JPEG) would make the task of playing with PNGs in plugins much easier.

I saw how Pictureflow imports JPEG libraries (by importing [sourceroot]/apps/plugins/lib/read_image.h), and how JPEG was imported to the API. I guess we could do the same with PNG, the problem is that
1) As far as I seen, PNG libraries don't have the same skeleton as JPEG ones (it's not as easy as renaming some variables and voids)
2) Because of what I described on 1, I don't have enough knowledge to edit/expand the API to add PNG support (my developing knowledges were almost learned in my own, and I'm still learing)
2.1) It seems to me that there is little to no documentation on the API so I can't learn by myself
3) Having me adding PNG support to the API would certainly be too much changes to include in a diff/patch

So, if someone could look into this issue, it would be greatly appreciated. Furthermore, after adding PNG support to the API, it would be more easy to add support to PNG albumart (PNG compresses much better than BMP and doesn't look blurry at high resolutions as JPEG).

Thanks for your help so far