Icon file format

[Ernie S.]

I'm new here. The name is Ernie and I'm an old fart that drives all over south Florida for business. I'm new to GPS and bought a TT ONE 125 and have been playing with options and customizing it to my liking. I see you have a forum dedicated to car icons and there are many requests for folks to make custom icons of people's rides. My personal transportation is a Harley Davidson so I played with making my own .BMP image. What I ended up with looked like all the icons that come in the TT, but mine displayed with a 1 px red border all around it. It looked like hell so I started playing a bit and found that .gif images could be used in place of .BMP's. Gif images have the advantage of being significantly smaller in file size than bitmaps and you can have borderless images that are transparent where a bitmap would have the typical red fill.
I'm a Linux user here. (no windows for me) I use an image editing program called "Gimp" It's nearly as good as photoshop and FREE! There is a windows version for the unenlightened available for download at GIMP FOR WINDOWS
With Gimp, you can erase background to transparent space, resize to 60 to 80 pixels and save as a .gif image before copying it over the the art/cars folder.

 

[JeanLuc_]

Great find about the GIF format! now I've not tried it yet, but I wonder if it supports PNG files too. If that is the case, we could have full alpha information and create proper vehicles icons with transparent glass!

 

[Ernie S.]

good question, but at 60 or 80 px, .gif is plenty. The TT OS is Linux. I wouldn't doubt it could handle PNG
The bigger question is why did the company load a unit with limited memory with relativly huge BMP's when there are several other formats that are significantly smaller in file size and would have allowed them transparency without secondary processing? Seems like a waste of resources to me.

 

[Hippie459MN]

I am going to have to try this out on my 720 and see if it works. If so it would make things so much easier.

 

[Ernie S.]

Was looking at 3rd party applications and from what I read, it's very likely that TT will recognize jpeg's png's and gif's as well as bmp's. Jpeg's might be useful foe splash screens, but gif and png have transparency that's perfect for icons for cars, poi's and favorites, maybe even custom icons in the menus.

 

[RobertB]

Well, easy enough to test! I already tried creating a BMP from the standard blue arrow with a transparent interior, and it works great (even though it's ugly -- I didn't work long on it). But png alpha-channel transparency would be fun to play with, so I tried it out.

Bad news, though.

I took the familycar.bmp, put it in Microsoft Photo Editor, and saved it as a .png. I even went in to mess with the transparency -- Microsoft Photo Editor has very few options, but that's good, 'cause I've never figured out how to do as much as draw a line with GIMP on my Linux box at home.

Copied testcar.png to TomTom. Went to "Change car symbol". It DOESN'T show up.

I saved the .bmp as a .gif, called it giftest.gif, and copied that to the unit. It showed up... but as a blank square, and when selected, the unit said "This picture cannot be used as a car symbol". There's probably something wrong with the file -- the program I used sucks, and I've used up my goofing-around time here at work. I bet someone who knows how to make the GIMP run won't have any trouble.

As for .gif vs. bmp, I think they're using .bmp's for a slight performance boost. The unit's processor isn't a quad-core behemoth, and every eliminated clock cycle helps. Processing a .gif involves decompressing out to... a bitmap. It takes a lot fewer clock cycles to just do an XOR on the mask (the red bits) and drop the bits onto the display. A .gif file shouldn't cause a performance drag during operation -- just during startup. But startup delays add up.

As for size, well, the .bmp files are all under 20kb. Sure, they'd be more like 2-3kb as .gif or .png, but that's still less than half a meg all together. That's not very efficient on a 1GB unit like mine, so I may convert my .bmp's to .gif's when I figure out what I did wrong with the last one (maybe it's a color depth problem). But for a larger unit -- or for a casual user who doesn't need a bazillion POI's -- the lost storage space is less important than the improved startup speed.

 

[Ernie S.]

try this .gif
Hmmm file size vs. processor overhead. Interesting.

 

[RobertB]

Ok, substituting splash.jpg (20k) for splash.bmp (226k) did not work. It just booted up with the tomtom logo. Substituting splash.gif (40k) didn't work either. Edit: Actually power-cycling (instead of disconnect/reconnect from TTHome) did something different: with the .gif present, the screen went grey for a bit. I think my .gif doesn't agree with the unit, just like my car .gif.

Your Dodge Ram .gif *does* show up, and is pretty cool to boot. I wonder if you made a .gif for the splash screen, if it might work?

 

[RobertB]

I road-tested the icon, and it looks cool. I didn't realize how well the perspective would match the 3d map.

But as I was going through a highway intersection, I noticed something -- the display was jerky, like it was operating at a lower frame rate than before.

I switched back to one of the standard .bmp icons, and the jerkiness went away.

I think the unit doesn't do what I thought, converting the .gif to a .bmp at startup. Instead, I think it performs the conversion at runtime! That would add a lot of processing overhead to each frame, reducing the frame rate noticeably.

If I'd programmed that part of the code, I'd have converted the .gif to a .bmp once -- maybe during that long initialization process that happens after downloading content from TTHome. Then use that .bmp.

But the unit isn't an icon display; it's a GPS, optimized for the driving experience. And if I were a project manager, I'd be hesitant to pull a coder off of route calculation so she could optimize a function (.gif support on car pix) that 99% of TomTom owners would never use.

 

[Ernie S.]

point taken, Robert, but if as you surmize, the .gif is converted for each frame, isn't the red being masked for each frame as well?

Yup, I tried .gif .jpg and .png versions of a spash screen too and only .bmp works. This, I think is a big mistake on TT's part. my home made splash.bmp is 225k and the same image with 15% compression in .jpg is 16k. Maybe this isn't a problem for high end units with SD cards, but for entry level units with 1 gig storage, this is a stupid waste of memory. So what if boot takes a half second longer. I want access to POI's, custom icons and other eye candy. I won't notice the time the processor takes to convert my splash to a useable format. Maybe .gif is not the right choice for car icons, but I think .bmp is a poor choice for the splash.

 

[RobertB]

You would think that converting the red to the underlying pixels would be a bear, but it's not. It takes boolean commands that are tricky to explain, but dead-simple for the hardware to perform:

* Make a "mask" from the red parts of the car icon.

* Turn the red parts black (0) in the car icon.

* In the "mask", make the red (transparent) part white (1) and the non-transparent part black (0)

* Use a bitwise AND (which is very, very fast) to combine the "mask" with the display.

* Here's where the magic comes in: use bitwise XOR (also very, very fast) to combine the "mask" with the combined image you created above. Voila, your truck shows up on the road!

If you want additional details, Microsoft has programmer-level information. But you can see it yourself right on your screen, whatever computer you're using. Move the mouse. That cursor is a bitmap with a color selected for transparency. You can move it as fast as you like, and XOR can keep up.

By comparison, displaying a .gif with transparency involves expanding the compressed data into a bitmap -- because a bitmap is the *only* thing the display really understands. And then extracting the mask... and then going through all the steps above.

Most modern programmers don't pay a lot of attention to those extra clock cycles, but for embedded systems programmers, it's essential. I started out with a TRS-80, which had a fraction of the power of my TomTom... I could tell some stories of assembly language, in the snow, both ways.

But as for the startup/shutdown screens... yeah, if they've got a routine to unpack a .gif already, why not enable it there, too? Maybe it's hardcoded in the transparency display routine -- a test of that would be to use a .gif for a POI image and see if it works like the car icon.