Want to help with JPEG and PNG

[sagiil]

Hi all,
Two days ago I installed Rockbox for the first time on my 5.5G iPod.
I really like it, and it works great, besides one thing that I miss from my old vanilla firmware - Embedded Album art.
I read some articles in the Wiki, and understand now that rockbox doesn't support JPEG and PNG formats, including resizing. This is really absurd situation, since supporting MP3 and FLAC codecs is much harder technically than JPEG or PNG, not mentioning resizing (which can be performed on-the-fly while decoding).

So.... Since I'm a graduated programmer, and have some experience with image processing, I thought I could help.
To be clear, this post is not about how to do it (SVN, Compiling, etc) but rather if to do it. In fact, since I don't have a lot of spare time during weekdays, I can work on it only in weekends, so I suppose the development can take some time, that a free contributor could do in half the time.

Then, my question is if someone is already working on this matter or is it development abandoned by now? Is it safe for me to work on it without do some double work another developer already done/doing?
Another question, is maybe trivial to some of you, but I'm a quite a newbie in developing free software - how It's preferred to consult other programmers - through the forum, mailing lists or IRC?

Besides that, I need to know some technical limitations:
* What's the size of the memory I can work with (for temporary buffers) in my algorithms?
* What's assumptions about the speed of the processing I can have? (since we have a space-time trade off, I need to know how to balance it that I won't hurt performance or exhaust all memory).
* Is a coder needed for JPEG or PNG, or a decoder is enough?

Thanks for you answers, they will help me decide whether to take on me this (not very) small project.

[AlexP]

Another question, is maybe trivial to some of you, but I'm a quite a newbie in developing free software - how It's preferred to consult other programmers - through the forum, mailing lists or IRC?

Very few devs read the forums - jump on IRC (or dev mailing list).  I'd get on IRC and chat about it!

[saratoga]

Besides that, I need to know some technical limitations:
* What's the size of the memory I can work with (for temporary buffers) in my algorithms?
* What's assumptions about the speed of the processing I can have? (since we have a space-time trade off, I need to know how to balance it that I won't hurt performance or exhaust all memory).

Performance isn't likely to be a big issue (decoding JPEG is extremely fast and I doubt PNG is much different), but memory is more of a concern.  We don't like to waste it, since some targets have little memory, and other need all they can get for buffering music from their disk drive.

[sagiil]

Okay, I'll keep that in mind..
I guess now all that's need to be done is to implement it

Edit:
Well, maybe I'm too late.. It seems that someone's already working on a PNG decoder (http://www.rockbox.org/tracker/task/9493). There is some progress on resizing (http://www.rockbox.org/tracker/task/9458?histring=resize), so I'll probably focus on that.

[saratoga]

I would look at the resize patch:  resizing and jpeg decoding will necessarily involve one another.  Optimal resizing should work together with jpeg decoding, since the cosine transform used by JPEG can be tweaked to resize (by a power of 2) for free. 

Probably what will happen is that the JPEG decoder will be given the current and desired size, and then by adjusting the inverse DCT properties will aim to get within a factor of 2 of the desired size, and then the resize code will handle the last < factor 2 resize via (bilinear) interpolation.  This should result in a considerable savings of CPU time for only a small increase in complexity.  An interesting side effect of this is that for files of reasonable size (less then about 5000x3800 for a 320x240 screen), larger files can be only a little slower, and sometimes even faster to decode then smaller ones.

The resize patch is a good place to start, since the jpeg codec basically sits directly in front of the resize code.

[soap]

I do not see a problem expecting people to have "reasonable" sized cover art.  Despite the marketers of flat-bed scanners 200 dpi is about all the true informationyou could ever expect to recover from a photograph, and that makes any CD cover scan over 1000x1000 just silly.
 

[robin0800]

Think there's a jpeg viewer in rockbox already!

[GodEater]

Yes, but its a plugin, it's not in the core yet.