Jump to content

  • Log In with Google      Sign In   
  • Create Account


Strange graphics file format


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
18 replies to this topic

#1 Stainless   Members   -  Reputation: 775

Like
0Likes
Like

Posted 13 April 2014 - 09:16 AM

Has anyone come across a graphics file format that starts with IMF 

 

The file extension is TGA, but it's not readable as a TGA file.

 

I know the short at offset 8 is the image width, and the next short is the image height.

 

The images are either 24 bits per pixel or 32 and are not compressed, well the file sizes don't suggest they are compressed.

 

A 128 by 128 32 bit image is 65,804 bytes

 

I have tried the obvious skip the header and load the rest as pixels, no good

 

Anybody come across this file format?

 



Sponsor:

#2 Buckeye   Crossbones+   -  Reputation: 4006

Like
1Likes
Like

Posted 13 April 2014 - 10:03 AM

I haven't run into files like that in particular, but a bit of googling implies it may be an ImageForge file.


Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.


#3 Mona2000   Members   -  Reputation: 574

Like
1Likes
Like

Posted 13 April 2014 - 10:34 AM

Some games (IL2, Theatre of War) use a format that matches what you describe. You can check with this.



#4 Stainless   Members   -  Reputation: 775

Like
0Likes
Like

Posted 13 April 2014 - 11:30 AM

Yes, that tool works so that is the correct file format.

 

I need to write my own loader for it though, I'll have a look at ImageForge and see if that gives me any clues.



#5 Mona2000   Members   -  Reputation: 574

Like
1Likes
Like

Posted 13 April 2014 - 12:23 PM

I don't think it's related to ImageForge, just a proprietary format made for those games. Did you try stripping the header (I think it has width, height and bit depth) and reading the rest of the file as a TGA image?



#6 Stainless   Members   -  Reputation: 775

Like
0Likes
Like

Posted 13 April 2014 - 01:07 PM

I've tried reading the files in multiple ways.

 

Things like straight 32 bit per pixel. four bit planes one byte per pixel, etc. No luck. I'll keep hacking away.

 

hmmm.. I wonder if you are right, I'll read up on the TGA header

 

 

No doesn't look like it

 

49 4D 46 1A 31 30 00 01 80 00 80 00 01 04 04 04 04 04 04 04 04 04 02 02 04 02 02 02 01 04 04 04 02 02 02 02 04 04 04 04 04 02 04

 

I     M   F        1                |width|height|

 

I've never seen a header like that before, all those 4's and 2's confuse the hell out of me


Edited by Stainless, 13 April 2014 - 01:17 PM.


#7 mark ds   Members   -  Reputation: 1118

Like
0Likes
Like

Posted 13 April 2014 - 05:15 PM

have you tried working from the end of the file - e.g. file length - width * height.



#8 Mona2000   Members   -  Reputation: 574

Like
1Likes
Like

Posted 13 April 2014 - 06:07 PM

If you upload the image we can have a look at it.



#9 Stainless   Members   -  Reputation: 775

Like
0Likes
Like

Posted 14 April 2014 - 02:10 AM

I've stuck one of these graphics on the project page as 

 

2bladedmetall.tga

 

http://stainlessbeer.weebly.com/il2-mod-tool.html

 

I'm giving back to the IL2 community, a while ago I used some of their meshes for a demo (not a commercial product) and now I want to pay them back with an app that helps modders test their aircraft.

 

It's almost complete, I just have a couple of issues left to fix, this graphic issue is the most annoying

 

Any help would be gratefully received



#10 TheComet   Members   -  Reputation: 1448

Like
0Likes
Like

Posted 14 April 2014 - 04:18 AM


49 4D 46 1A 31 30 00 01 80 00 80 00 01 04 04 04 04 04 04 04 04 04 02 02 04 02 02 02 01 04 04 04 02 02 02 02 04 04 04 04 04 02 04

The section after the image width and height look like flags that were OR-masked together.


Edited by TheComet, 14 April 2014 - 04:18 AM.

YOUR_OPINION >/dev/null


#11 Stainless   Members   -  Reputation: 775

Like
1Likes
Like

Posted 14 April 2014 - 05:31 AM

Okay getting somewhere ...

 

Looks like the pixels are stored as differences. Seriously strange.

 

Using that tool, I converted the IMF file to tga and compared the two files.

 

The TGA file starts with a pixel 9D,9D,9D,00   and I can see that in the IMF file.

 

The TGA version continues with a bunch of the same pixels, the IMF with a bunch of 0,0,0,0

 

Further on I can see a pixel 9c,9c,9c,03 and in the IMF file FF,FF,FF,00   

 

And again later on the TGA goes back to 9d,9d,9d  in the IMF file I can see 1,1,1,     

 

It doesn't all fit yet, but the mist is clearing a little



#12 Mona2000   Members   -  Reputation: 574

Like
2Likes
Like

Posted 14 April 2014 - 06:11 AM

It's some weird ass proprietary format:

 

7 bytes - magic

1 byte - mode (0 = 24 bit, 1 = 32 bit)

2 bytes - width

2 bytes - height

height bytes - color row modes (0 = ???, 1 = row is stored as diff starting from 0, 2 = row is stored as diff starting from previous row end value, 3 = ???, 4 = ???)

color row 1 (1 byte r, 1 byte g, 1 byte b)

color row 2

.. (up to height rows)

height bytes - alpha row modes (same as above)

alpha row 1 (1 byte a)

alpha row 2

... (up to height rows)



#13 Stainless   Members   -  Reputation: 775

Like
0Likes
Like

Posted 14 April 2014 - 06:46 AM

That's interesting, I'll give it a try.



#14 Stainless   Members   -  Reputation: 775

Like
0Likes
Like

Posted 14 April 2014 - 07:14 AM

That's much closer, I'm getting structures now.



#15 Mona2000   Members   -  Reputation: 574

Like
2Likes
Like

Posted 14 April 2014 - 07:23 AM

I was wrong about the modes, mode 1 means it's the difference from the pixel at (x - 1, y), mode 2 means it's the difference from the pixel at (x, y - 1). Still no clue about the other modes.

Edit: mode 3 is the difference from (pixel[x - 1, y] + pixel[x, y - 1]) / 2 or something like that


Edited by Mona2000, 14 April 2014 - 07:41 AM.


#16 LorenzoGatti   Crossbones+   -  Reputation: 2585

Like
3Likes
Like

Posted 15 April 2014 - 03:19 AM

I was wrong about the modes, mode 1 means it's the difference from the pixel at (x - 1, y), mode 2 means it's the difference from the pixel at (x, y - 1). Still no clue about the other modes.

Edit: mode 3 is the difference from (pixel[x - 1, y] + pixel[x, y - 1]) / 2 or something like that

These appear to be the PNG filters. 1,2,3 correspond; other possible values include 0 (unaltered pixel) and 4 (Paeth predictor, see the PNG spec). Filter type 3 has a floor operation: the reference value is floor((pixel[x - 1, y] + pixel[x, y - 1]) / 2) in your notation.


Produci, consuma, crepa

#17 Stainless   Members   -  Reputation: 775

Like
0Likes
Like

Posted 15 April 2014 - 05:47 AM

Brilliant catch, it's so close now. 

 

I have probably got an accuracy issue in mode 3, or a bug in my Paeth predictor, but most of the image is now correct.

 

Thanks guys



#18 Stainless   Members   -  Reputation: 775

Like
0Likes
Like

Posted 15 April 2014 - 06:05 AM

progress report, so close now.

 

3541046_orig.png



#19 Stainless   Members   -  Reputation: 775

Like
1Likes
Like

Posted 15 April 2014 - 10:45 AM

Ok, this has been fun. It's a long time since I just stared at a hex editor looking for structure. Kinda miss it.

 

Anyway the problem above was caused by an initial value problem. In mode 4 the first pixel in a line has to be set to be the same as the pixel directly above it, in all other modes it has to be set to zero.

 

Then you run the relevant filter, really strange.

 

Well I have 24 of these graphics, my code now loads 23 of them perfectly. Why one graphic has a glitch, I don't know. The code will do what I need it to now, so I'm stopping.

 

Thanks for the help and ideas guys.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS