[Announce] View MBM 1.10

[JOM]

Hmph,

Might as well release something, too many things done and just waiting for announcement... Happy to tell that I could not crash 1.9.5 Listbox Few minor things under consideration, but so far looks really nice.

"View MBM" is a developer utility to check what is inside all those built-in MBM graphics files. Released as source code, compatible with both PyS60 1.4.5 and PyS60 1.9.5.

http://jouni.miettunen.googlepages.com/viewmbm

Version 1.10, release date 2009-05-26

* Dynamic MBM file scanning in z:\resource\apps directory
* Dynamic count of graphics items inside MBM file
* Better error handling
* Tested with 5800 XM (PyS60 1.9.5)
* Tested with N82 (PyS60 1.4.5)
* Tested with S60 3.1 emulator (PyS60 1.4.5)

As far as using built-in MBM file graphics in your own apps, better forget that idea. At least when using raw index numbers, the most important file avkon2.mbm just doesn't keep consistent between platform releases. Most unfortunately. Also the only way to make it future-proof would require having PyS60 built-in into each device. Nice idea, but not very likely to happen in near future.

Better pack all your own graphics into custom MBM and include inside your own SIS.

Cheers,

--jouni

[w00k]

nice tool, btw, why you did not add mif view too? in pys60 1.4 is possible, should be with 1.9 too

[JOM]

nice tool, btw, why you did not add mif view too? in pys60 1.4 is possible, should be with 1.9 too

Would love to, just tell me how to find out number of items inside MIF file Ok point me to file format specs, could take a look at that.

Yep, the code already works ok as-is, just get a crash when I try to use items which don't exists... There are already weird crashes from MBM, which are supposed to contain certain number of items, but something gets wrong. Had to put together a rather complex try-catch system to keep sw up and running with "bad" MBM data.

Cheers,

--jouni actually surprised "View MBM" doesn't crash or leak memory

[marcelobarrosalmeida]

Would love to, just tell me how to find out number of items inside MIF file Ok point me to file format specs, could take a look at that.

JOM, try the following:

# marcelo barros de almeida
# tested with Python 1.9.5 only (Nokia E71)
# 
import struct
from appuifw import *
import os
import e32

mif = u"z:\\resource\\apps\\avkon2.mif"

fd = open(mif,"rb")
# decoding header
hdr = fd.read(16)
(mif_id,mif_type,next_sect_offset,num_imgs)=struct.unpack("<LLLL",hdr)
fd.close()

icons = []
for n in xrange(num_imgs):
    icons.append((os.path.basename(mif),u"",Icon(mif,n,n)))

app.body = Listbox(icons)
lock = e32.Ao_lock()
lock.wait()

I spent some time analyzing the mif files and I am starting to understand its structure.

For mifs generated by me (mif type 2), I could see that it has a header (16 bytes long) with a magic number mark (B##A) followed by a number that I guess is some mif type (2) and next section address offset. After, we have the amount of images in the mif file (what you want). All these variables are 32bits and the format is little endian.

For mif type 2, at next section position we have a table. This table has several entries with two 32bits numbers: image offset inside mif file and size. And you have an entry for the image and for its mask (so, use offsets 0, 2, 4, ... when using appuifw.Icon(file,offset,offset)).

Finally, each image is appended after this header but with an small header before raw image data (32 bytes long) starting with another magic number mark (C##A).

However, it seems that we have different mif types. For instance avkon2 is type 3 and the table is missing. An additional number is appended to the header as well. Image header are equal but with some different numbers.

I could not find any spec but I will organize this info and publish it soon. May be useful. I saw some related code inside ensymble repository as well.

[JOM]

Wonderful !!!

Last evening I was dead tired, dropped on bed at 2200 and woke at 0900. Got to sleep once a week, I guess Hopefully can continue experimenting this evening, with your code.

One comment, from earlier experiments: got to use the real MIF indexing, using relative 1, 2, 3 etc. will cause random crashes. More often than not. No such with correct indexing! Also than for the file format tip (2 vs 3). I did notice that, but thought actually that all user made would be type 2 while all on ROM would be type 3. Would have next checked the compression method and tried to open it, however now I'll continue with type checking

Thanx,

--jouni

[marcelobarrosalmeida]

Jouni,

I hacked a lot and my conclusion are below:

1) MIF file type 2 are simple the images count seems reliable. The header is below, the first 4 longs of mif file. All bytes are little endian. So:

Ex: first 16 bytes of wordmobi2.mif:

42232334 02000000 10000000 10000000 

-> magic number: 42232334 (B##4)
-> mif type: 02000000 (2)
-> next field offset: 10000000 (16)
-> image count: 10000000 (16, for this example)

After, we have the table listing all image positions and sizes:

Ex: offset 16 of wordmobi2.mif

90000000 971D0000 (image 0)
90000000 971D0000 (mask 0)
271E0000 310D0000 (image 1)
271E0000 310D0000 (mask 1)
...

-> offset from beginning of file: 90000000 (144)
-> size: 971D0000 (7575)

In this case, image and mask are equal and points to the same location.

Each image has its own header, with 32 bytes. It is easy to see the magic number (C##4) and the amount of bytes in the image, not counting header.

Ex: image section header for an image in wordmobi2.mif

43232334 01000000 20000000 771D0000 
01000000 0B000000 00000000 00000000

-> magic number: 43232334 (C##4)
-> unkown
-> unkown
-> image size: 771D0000 (7543)
-> unkown
-> unkown (1, 4, 6, and sometimes 7)
-> unkown
-> unkown (I saw 0, 1, 4 here)

I analyzed *several* image headers and fields 6 and 8 sometimes change. But I couldn't see any relationship.

We may see non compressed images inside the file. And extract them easily. I did this for my own file (wordmobi2.mif). There is a program for extracting compressed svg but it not worked for me when I compressed my mif file. But it works for avkon2.mif (you need to change the first long of the image, from CE56FA03 to CC56FA03). Of course, this may be illegal and I will not publish the results here or even recommend that you do it. It is better to check the copyrights of the images first.

2) MIF type 3 (ROM?) does not have the images table. And its header seems to have 5 fields. I am guessing that the last field is some CRC. I tried CRC32 over some parts of the file but the CRC was different. Images are the next field, at position indicated by the third field in the header:

Ex (avkon2.mif):

42232334 03000000 14000000 5A040000 
CF272810 ( ==> IMG start here 43232334 01000000 20000000)

-> magic number: B##4
-> mif type: 03000000 (3)
-> next field offset: 14000000 (20)
-> image count: 5A040000 (1114)
-> CRC ??: CF272810

So, the number of images is a mystery. Header says 1114 but I could find only 423 image marks (C##4). Multiple layers images ? I don't know. Moreover, Python 1.9.5 loads all 1114 images while Python 1.4.5 loads only 233 images.

3) I saw some files with mif type 1. They were similar to mif type 2.

So, that all, my mif hacker session ends here.
I changed ViewMBM just to test (attached) and several mifs could be opened.

[JOM]

Thanx Marcelo,

Just to report I integrated your code, got some of that already, and will do some testing. Few notes to your MIF document - which btw is great! Hope you'll actually write it clean in some place! Wiki maybe?

Under S60 3.1 emulator I got mixed results: 1.4.5 and 1.9.5 handle MIFs in different way, indexing starts at 16384 in 1.4.5 and 0 at 1.9.5. There was a bug report + fix, saying that MBG file generated during creation of MIF has index values, which were not accepted, but should have been. Can't find it now, will later if needed.

Also found an explanation to KErrEof crash, from Knowledge Base of all places! So now it's confirmed that max number of items inside MIF is KMaxTInt16/4 (8192).

At breakfast,

--jouni

[JOM]

Current version in progress, works pretty nicely with PyS60 1.9.5 in N82 and 5800. Some variation for 1.4.5 and 1.9.5, but more to come. Also will improve usability a bit, at least planning some

http://jouni.miettunen.googlepages.com/viewmbm

Version 1.30, release date 2009-06-01

* Support MIF files
* Some variation between PyS60 1.4.5 and 1.9.5
* Thanx to wizard_hu_ and Marcelo Barros for MIF help !!!
* Tested with 5800 XM (PyS60 1.4.5 and 1.9.5)
* Tested with N82 (PyS60 1.4.5 and 1.9.5)
* Tested with S60 3.1 emulator (PyS60 1.4.5 and 1.9.5)

Most biggest thanx to Marcelo Barros for figuring out MIF file format! Wizard_hu_ was faster, but Marcelo was more complete

Known defects: PyS60 1.4.5 and 1.9.5 handle MBM/MIF files in different ways. At least one file can be opened with 1.4.5 but not 1.9.5 - or was it vice versa. Will write a defect report as soon as I have a moment to think...

Cheers,

--jouni on long summer vacation with three hyperactive kids building and painting dinosaurs, wondering what kind of dino sw I could write with PyS60

[marcelobarrosalmeida]

Thanks, JOM. I will add some nice pictures and publish at wiki in the next days. This way, I hope we can receive more contributions soon or the real spec.

[marcelobarrosalmeida]

Thanks, JOM. I will add some nice pictures and publish at wiki in the next days. This way, I hope we can receive more contributions soon or the real spec.

Info now at wiki: http://wiki.forum.nokia.com/index.ph...rmat_internals

[JOM]

Info now at wiki: http://wiki.forum.nokia.com/index.ph...rmat_internals

Looks good, thanx!

Cheers,

--jouni