On Sun, Jun 9, 2013 at 1:42 PM, Ladislav Laska <laska@kam.mff.cuni.cz> wrote:
progress, since there are no resources on the gpi file (I don't expect full
manual, but perhaps notes would be great) and testing stuff is really slow
(loading a file to gps, unplugging form usb, turning on, looking around,
connecting again...).

Welcome to life debugging/developing for Garmin file formats. It's not very much fun.

0) Get some geocaching extensions working (I can do this on my own, no help
needed, but recommendations welcomed).

While it's tempting to start building descriptions with, say, decoded hints and difficulty and terrain and such, please be sure to NOT do so by default as that would make the GSAK users grumpy when we took their carefully crafted geocache-isms and then added our own into them.

1) Get images working. The current state is, that I have image, but it's badly
garbled. I don't know if the problem is in incompatible bmp (I've tried some
variants, specifically indexed and non-indexed, various color depth) or the
bitmap format used in gpi (I have noticed that the hardcoded image is larger
than the image produced from bmp).

Images work on other devices.  This probably means that Garmin has done something wacky for your specific device.  There are then thus two steps to working that out.  First, you have to figure out the details of the image needed/used.  Second you have to figure out how that alternate image is represented in the file so  you don't wreck other devices.  They may, for example, be including multiple images for devices of different resolution and graphics capabilities.
 
2) Get more images working. I want to have image for each geocache type...

As you say, multiple files is probably the way to go on that.

 
3) Improve the code a little, maybe add some more comments and write down some
notes on the format.

We accept comment patches.  Just be sure they're relative to the top of the development tree from code.google.com/p/gpsbabel to make them easier to apply.


 
To the point on images -- they appear quiet large (larger than images I've got
from my friend's gpi from garmin's poiloader) and garbled. I would think that

That's pretty much the way to debug things like this - throw a file into POIloader and see what it does.  Be prepared to spend a long time staring at hex dumps.  When you think you've mutated garmin_gpi.cc into doing what you want, add tests to testo.d/garmiin_gpi.test to be sure you didn't break anyone else and that nobody else breaks your new stuff for the future.

the gps is reading the image in 24 bits per color or something like that. I
don't really know...

That's entirely possible.  You may have to extract the bmp out (maybe they've moved to jpg or something) and feed it to various image tools on a computer to see what they've done.

They've changed the image format a few times.  Historically, GPSBabel has relied on making the user provide the 'right' images, but now that we have Qt available, we could probably use QImage to take some of the edges off.
 

Some specific questions I have are:
1) Are there any notes on this format, perhaps from someone who wrote the code?
Was this code inspired by some other software?

To the best of my knowledge, Olaf (who is no longer with the project and who hasn't answered emails in years) did it from scratch.   While parts of the format are reasonably straight-forward to reverse engineer, I have no idea how he recognized that recursive bounding-box segment thing.  He was quite good at that sort of thing.

It's been a while since I looked, but we were the only open source program that did gpi.  At a glance right now, I don't see that's really changed.  

 
2) Who wrote or maintains this code? Maybe we could talk about it and share some
information.

Everything we know about that format is in the code.
 
3) Is there any good way to do testing and/or debugging? Some online reader?
Good windows app?

I think most of the online readers are actually using GPSBabel.   Certainly, there's some value in testing gpsbabel's writer against our own reader (and it lends itself very well to automation - that's the core of what our test suite does) and in comparing against POILoader's output (which rarely computes byte-identical output for non-trivial input because of differences in that aforementioned bounding box thing) but the acid test really is seeing what the devices will read.

Good luck.  It's a difficult process and we welcome a hand with it.