Help with filespecification...

can't seem to get the file?

Yes,

http://hem.passagen.se/bighatsmallfeet/map-problem.zip

is not valid...

Strange... But I only tested the link using the Run-function in the Start-Menu. Either try that, or try this link instead:

http://hem.passagen.se/bighatsmallfeet/map-problem.htm

/Daniel

Damn, it didn't work either! Then I suppose you have to try the RUN-option instead. Or I'll e-mail you the zip-file instead.

It seems to work in XP, at least. My ordinary homepage is down for the moment, so I'm using a free one... Not so good, it seems.

/Daniel

RUN-option?

There is a bundle of free web hosts; signup for one, make a dummy page, and post your file there so you have more experts working this out for you...

Oh, I feel stupid... Now let's see if I can figure this out...

http://hem.passagen.se/bighatsmallfeet/map-problem.htm

Try clicking on the link on the page above, and you should be able to fetch the zip-file.

/Daniel (not an HTML-expert, hehe...)

hello Dippen, I took a look at the .rik files in your zip, these might require ALOT of work to figure out with out the file's constuction info. However, since I have worked with alot of image formats, I couldn't help but notice the simularities in the file sizes for the .rik files and .gif files, especially for the single color sea.rik file. So I made a 256 color .gif file from the sea.bmp you had and I got a 156 byte match at the end of the sea.rik file with the .gif file, although the palette entries didn't match, since your .bmp was 24 bit. A 156 byte match is to many for coincidence. I suspect they choped off 13 or more consistant bytes fron the begining of the a .gif file and then tacked on thier header. Mabey if you got the .gif file header specs you could figure out which consistant (non changing) bytes they removed and replace them to get a .gif file, or maybe not? ? ? I guess you tried to get the file constrution data?

This is a fantastic clue, Slick! I'll look into it right away. But what do you mean by the last sentence "...file construction data?"

/Daniel

what I meant by file construction data, , , is to ask the people who created the program about how the files are constucted, although this might not be posible at all.

Also, if you had an 8 bit bitmap of the sea.bmp with the same color palette as used in those .rik files then you could use a graphics program to turn it into a sea.gif file and compare the bytes to see what you need to remove and what you need to add to get a workable .gif file.

I've talked to the people who are responsible for the file format (the Swedish Landsurvey-department), but they wouldn't give me the specification because "it would promote illegal copying of the maps"... Figure that one out!

I'll try to figure the thing about the gif-conversion out. Let me know if you come up with any more ideas. And if nothing else comes up I'll gladly give you the points just for pointing me in the right direction.

/Daniel

can you get me a 8bit bitmap of the sea.bmp with the same color palette? maybe on that web site

How do you mean? Sorry I'm slow... Not very used to graphic formats... :-)

Ok, graphics and  pallettes, a 24 bit bitmap does NOT have any palette colors, it sets all of it's colors from 3 bytes for the red, green and blue values for each pixel (3 bytes per pixel), an 8 bit bitmap defines 256 colors in whats known as a palette consisting of 256 colors, 3 bytes each, red, green, blue. It sets the color of each pixel with only ONE byte (0 to 255, an index of the 256 color pallette) You can change the palette of an 8 bit bitmap and the the colors shown will change even though you did not change any of the pixel's color index number (byte). If I had a 8 bit (256 Color) bitmap sea.bmp with the same pallette (identical pallette 256 color defintions), then I could create a sea.gif that would be useful for comparision. May you could lower your desktop screen color depth to 256 colors and do a screen capture for the sea.bmp, this assumes that the program showing the map has realized the palette for the map to the application.

about the gif file header, according to the info I got from the web the first 6 bytes are ASCI text for the version of the gif
first six bytes - GIF89a
the next 2 bytes are a Word value for the Width (pic width)
the next 2 bytes are a Word value for the Height (pic height)
the next byte is the number of PackedFields (colors in pallette, I think)
the next byte is BackgroundColorIndex
the next byte is the AspectRatio - actual ratio = (AspectRatio + 15) / 64

I've also found info about the GIF-file specification, and after look into it, I'm sure that the data is LZW-compressed (as in a GIF-file), but that transforming the .rik into a .gif would be difficult since the .rik is constructed from the lower left corner and upwards toward the upper right corner.
   Instead, by writing my own LZW-decoder (or using an existing one), I could solve the problem quite easily. Do you know of any decoder? I'm sure I could write one, it's just the speed I'm worried about.

/Daniel

I've found some information regarding the GIF-specification on this site:

http://www.serve.com/jb/

As it is described there, GIFs are built from the upper left corner, row by row, down to the lower right corner. But the map-files are built the other way around, starting at the bottom. So I think the Landsurvey-department only used the LZW-compression method to get their files smaller, and that's whay you got the 156 byte similarity in the .gif and .rik-files. But anyway, you've pointed me in the right direction, so now all I need is a fast LZW-decoder. And it shouldn't be to hard to either write myself or find on the Internet. If you find anything else out (especially if you run into a LZW-decoder somewhere), let me know, but I'm accepting your last comment as an answer now. OK?

Best regards, Daniel

this may help you, it seems to have the gif compression stuff in it, but I donn't have time now to really look at it, you can get it as a gip fil at my web site


http://www.angelfire.com/hi5/delphizeus/gifzip.html