GPSFS Utility Program

[MIB.42]

Thanks Codaz, this is exactly the feedback I was looking for! Let's see :

1 If you open a GPSFS* file, eg GPSFS 1 2 3 4 etc it says TOO MANY tiles. That is strange.

Only the GPSFS ( and NOT! the GPSFS1/2/2/3/4 ) files have the information on the tiles. GPSFS1/2/3/4 files simply contain the image dumps.

At the moment I am not doing any super extra error checkings to see if you "obeyed" the basic rule of "Select the GPSFS file only"...

2 If you analyse a file, and then accidentally select OPEN FILE, you can't go back to the program because it freezes.

I tried this several times and saw no freezing. Altough it takes quite some time for windows to delete/reinit the list box, especially if there were throusands of entries. Be patient...

3 Also why can't i delete level 0 ? I don't like em. Because it's a picture from half of the city and i can't see anything usefull on it.

Level 0 is the root map. It does not make sense deleting it. It also is the smallest, only 4 tiles.

4 And there are level 1 tiles in my map (so they fill up space !) but they are empty ? So can you delete them ?

Empty maps do not occupy any image space, but are important for map logistics. They only occupy a mere 8 bytes each in GPSFS.

5. The CTRL + A function doesn't work for selecting all tiles at once, can that be fixed ?

I'll look into that. Why would you want to select all tiles?

6. My _MAP directory is 7 mb large, but the Util says: No Recompress, map size is 9.44 mb. Why is that ?

It is very likely a PNG based map. v0.1 does not have PNG-recompression capability. It will recompress PNG based maps in JPG. To have roughly the same image quality, it would require that many bytes. I will fix this in probably v0.3 or so. Meanwhile, I found that if you go around 70~80% of your original PNG based files, it still produces a pretty decent quality files...

7. I'm working on a laptop. For heat issues i downclock my CPU to 800 mhz. If i let it run at normal speed (1.73 GHZ) the ETA isn't correctly updated. It goes down yes, but my CPU is working twice as fast so it must be done sooner. The analysing is done faster so why isn't the ETA updated ?

ETA is almost impossible to compute precisely. I wanted to omit it altogether, but decided to leave it. Now I am thinking it was a mistake. The reason is, that if the maps have a lot of "holes" as in empty tiles or missing levels, there is no recompression necessary, thus it speeds up. At the moment the ETA is a very dumb; "How many tiles have I done in the past x seconds, thus I'd need y seconds more to do all of them"... I might just do a pre-run phase to do a pre-analysis on ETA as well, but that might take a few seconds, which will come from the analysis time... I wasn't sure if it was worth it... Based on your feedback, it surely is now.

VERY USEFULL PROGRAM, the faster your pc is the faster the program goes !

If you implement the feature from GMDL that checks if the tiles arent broken, and pops up to redownload them, it would sure be a real all-in-one map solution.

Or maybe you can give the code from your program to In7ane so he can implement this in his tool.

I hear you on the missing tile download! As far as I know GMDL already has that feature...
GPSFS_util is a simple post-processing program with some extra features. The real hard-work is in GMDL!

[MIB.42]

Nice, GREAT work MIB ! Is there any GZLIB or other LIB compression possible in the future ?

Because maps can be MUCH smaller. I don't care if map loading takes half a minute, if maps are significant smaller (150-200% compression) than i prefer compression.

I've looked at this in the past. As you probably know, both JPG and PNG files already have heavy compressions. After I applied aggressive zlib compression, I got 16% compression on PNG based maps and 3% for JPG based maps. And this was for compressing the whole GPSFS file and NOT individual tiles. If I did individual tile compression, the result was less than half of this due to per-tile compression table overheads.

The CPU load on the PSP for decompressing (inflating) was significant, thus battery life could be reduced as much as 30~40 percent! I don't think it's worth it...

Cheers,
MIB.42

[MIB.42]

if possible porting this progran for running in linux?

Oh man, it took me 2 weeks to port my initial code from Linux to Windows... While the core still works under Linux, the UI won't. I'd have to go back and rewrite the .RC based resouce management... I'd rather spend my time on feature development... *sigh*
( Does GMDL run under Linux? )

[Codaz]

Ok great ! What about grey-scaling the images or going to 16-bit color ?

O before i forgot, the feedback on your program took me a whole half our to type and think about

And why did you choose JPG or PNG ? Maybe GIF/TIFF/ JAS could be smaller.

JAS seems to be VERY usefull.

http://www.why-not.com/articles/formats.htm#JAS

Only problem is the psp can't read JAS files.

O and about the Linux problem, you CAN run Windows programs on linux running WINE.

[MIB.42]

Last thing, i created a simple BAT file for you guys that can rename the N_GPSFS to normal files, have fun !

Suggestion on naming the resulted files are welcome!
- I thought of renaming the original GPSFS files to O_GPSFS, but I thought if you want to try several recompressions, this might be awkward...
- I thought of creating a subdirectory like RECOMPRESSED_date and put the new files in there, but had some possible directory creation problems due to access control sometimes... I might just revisit this one...

Any ideas, suggestions?

[MIB.42]

Ok great ! What about grey-scaling the images or going to 16-bit color ?

For v0.3. I plan on adding color-reduction to 16 color for PNGs. Haven't thought of the 16-bit reduction for JPGs. Good idea! I'll look into it. Thanks!

O before i forgot, the feedback on your program took me a whole half our to type and think about

Much obliged! Keep'em comin'!

Cheers,
MIB.42

[MIB.42]

And why did you choose JPG or PNG ? Maybe GIF/TIFF/ JAS could be smaller.

JAS seems to be VERY usefull.

http://www.why-not.com/articles/formats.htm#JAS

Only problem is the psp can't read JAS files.

PNG - generally - has better compression than any of the above. It most certainly is better than TIFF and/or GIF. Not sure about JAS, but I'd be really surprised if it was otherwise... JPGs have excellent compression - better even than PNG - on "real" imagery, like satellite photos etc. due to it's lossy approach...

O and about the Linux problem, you CAN run Windows programs on linux running WINE.

You're right. Also see Lindows / Linspire...

[Codaz]

At what map size is your tool able to recompress it. I have now 5 test maps which are 10 mb of size.

On ALL of those 5 your util wasn't able to recompress to a smaller size.

Only on my large map of 300 mb, but it takes until tomorrow morning to analyze that :S

Your util should be able to remove levels BEFORE it analyzes them

Last addition for 2night: maybe you can add image ripple to the jpegs. If they are loaded they appear as "blocky" but if they are fully loaded (eg if you drive near them) they are displayed fine.

Now i have the idea that Mapthis is loading my 300 mb map in total and that's not good.

[MIB.42]

At what map size is your tool able to recompress it. I have now 5 test maps which are 10 mb of size.

On ALL of those 5 your util wasn't able to recompress to a smaller size.

Only on my large map of 300 mb, but it takes until tomorrow morning to analyze that :S

I am a bit surprised on those 10MB ones. I have several ones as well and one - which is 6MB - got recompressed to 3MB!

Are your files PNG based ones?

[Codaz]

Yes PNG. So waiting for 0.2 or 0.3 then

BUT befor i forget:
those are old maps, created with GMDL .011 or something. I can recreate JPEG maps with GMDL.

Is JPEG better or PNG ?

I want smalles images possible.