MAKIchan image format?

Ask for help and post your question on how to use XnView Classic.

Moderators: XnTriq, xnview

Post Reply
Ben321
Posts: 39
Joined: Fri Jul 30, 2010 8:05 am

MAKIchan image format?

Post by Ben321 » Tue Aug 23, 2011 6:45 pm

Ok I've seen this format for a while now as relating to images on the Japanese computer PC98. It has a file extension of MAG. Unfortuneately all documentation I've seen so far is written in Japanese. Now I know that XNview supports this format. So I'm hoping that maybe someone here at these forums can explain to me how it works. I've tried reverse engineering this but all I get is garbage (often from only slightly altering one byte in the file). This suggests it uses some kind of compression. Now if only someone here could explain the format to me, in English.

Thanks in advance for any help you may provide.

User avatar
Clo
XnThusiast
Posts: 4441
Joined: Sun Oct 17, 2004 4:57 am
Location: Bordeaux, France
Contact:

Re: MAKIchan image format?

Post by Clo » Tue Aug 23, 2011 7:29 pm

:arrow: Ben321

:) Hello !

• I can't explain the structure of this format, but all I can say is from my old doc :
mag---- MAKIchan Graphics----ext. : mag
- XnView supports it at reading only

:mrgreen: KR
Claude
Clo
Old user ON SELECTIVE STRIKE till further notice

mimulus
Posts: 3
Joined: Sun Aug 28, 2011 1:24 pm

Re: MAKIchan image format?

Post by mimulus » Sun Aug 28, 2011 1:28 pm

While working on a visual novel engine, I've happened upon a few MAG images, and wrote a basic specification. It is available here: http://mooncore.eu/mimu/txt/makichan.htm

Helpful, I hope!

User avatar
Clo
XnThusiast
Posts: 4441
Joined: Sun Oct 17, 2004 4:57 am
Location: Bordeaux, France
Contact:

Re: MAKIchan image format?

Post by Clo » Sun Aug 28, 2011 3:51 pm

:arrow: mimulus

:) Hello ! Welcome aboard !

• Thank you for this link!
- Maybe Pierre (the Author) will find there some useful info…

- The best should be indeed to find a Japanese user able to translate the full specs… Image

:mrgreen: Kind regards,
Claude
Clo
Old user ON SELECTIVE STRIKE till further notice

Ben321
Posts: 39
Joined: Fri Jul 30, 2010 8:05 am

Re: MAKIchan image format?

Post by Ben321 » Wed Oct 05, 2011 10:27 am

mimulus wrote:While working on a visual novel engine, I've happened upon a few MAG images, and wrote a basic specification. It is available here: http://mooncore.eu/mimu/txt/makichan.htm

Helpful, I hope!

Yes BIG THANKS, but you neglected a few things I'll need to know if I'm to make an encoder. What do the boolean values in flag A do? Also you explained how to use flag B to copy pixels, but not how to set flag B to make original pixels. Please explain in more detail how flags A, B, and the color array work together to make an image.

Also please list other screen modes than just mode 04 (16 color mode) if you know what the codes are for other screen modes.

mimulus
Posts: 3
Joined: Sun Aug 28, 2011 1:24 pm

Re: MAKIchan image format?

Post by mimulus » Mon Oct 17, 2011 5:31 am

I updated the specification document, hopefully making it clearer. I also translated the screen modes as listed in the official Japanese specs.

You're hoping to write an encoder? Hmm. If you don't care about compression, I think this might work: fill the flag A buffer with only zeros, and presumably the entire image will be directly read from the color word array.

quietroit
Posts: 1
Joined: Wed Nov 02, 2011 2:16 pm

Re: MAKIchan image format?

Post by quietroit » Wed Nov 02, 2011 2:26 pm

mimulus wrote:If you don't care about compression, I think this might work: fill the flag A buffer with only zeros, and presumably the entire image will be directly read from the color word array.
By the way, very good tip

Ben321
Posts: 39
Joined: Fri Jul 30, 2010 8:05 am

Re: MAKIchan image format?

Post by Ben321 » Wed Aug 01, 2012 5:53 pm

mimulus wrote:I updated the specification document, hopefully making it clearer. I also translated the screen modes as listed in the official Japanese specs.

You're hoping to write an encoder? Hmm. If you don't care about compression, I think this might work: fill the flag A buffer with only zeros, and presumably the entire image will be directly read from the color word array.
Does that mean that there would be no Flag B array? And does that also mean that the header entry for Flag B size would be set at 0? If so, What would I set the header entry for Flag B offset too? Would it be the same entry as the Color Index array offset? Please explain further. Your suggested technique sounds good in theory, but you didn't provide enough info for actually implementing it.

mimulus
Posts: 3
Joined: Sun Aug 28, 2011 1:24 pm

Re: MAKIchan image format?

Post by mimulus » Sat Nov 10, 2012 3:16 pm

Does that mean that there would be no Flag B array? And does that also mean that the header entry for Flag B size would be set at 0? If so, What would I set the header entry for Flag B offset too? Would it be the same entry as the Color Index array offset? Please explain further. Your suggested technique sounds good in theory, but you didn't provide enough info for actually implementing it.
By now you've probably gotten it to work perfectly, but just in case:

As far as I can tell, your guesses are all correct. The Flag B array would be empty, its size would be 0 bytes, and its offset equal to the Color Index array offset. Or, you could put a bunch of garbage data in the Flag B array - a decompressor would just never read it, as long as the Flag A array is all zeroes.

This is obviously just an inefficient hack; figuring out a good algorithm for optimal Maki-chan compression is a challenge of its own, while I only needed decompressing capability.

Ben321
Posts: 39
Joined: Fri Jul 30, 2010 8:05 am

Re: MAKIchan image format?

Post by Ben321 » Wed Jan 09, 2013 8:55 am

This is an overly complex compression scheme. The choices for DeltaX and DeltaY values make no sense, they don't seem to have any pattern:
deltax : array[0..15] of byte = (0,1,2,4,0,1,0,1,2,0,1,2,0,1,2,0);
deltay : array[0..15] of byte = (0,0,0,0,1,1,2,2,2,4,4,4,8,8,8,16);
They seem to be just arbitrary values pulled out of the inventor's hat.

The color channels are GRB instead of the standard RGB or BGR.

It uses a complicated XOR scheme:
If (next flag A bit) = TRUE
Then flag_buffer[x] = flag_buffer[x] XOR (next flag B byte)

instead of just a simple equal to scheme like
If (next flag A bit) = TRUE
Then flag_buffer[x] = (next flag B byte)

It actually bothers to keep a flag buffer such that the previous line's actions with flagB have an effect on the current line, although that is a dumb thing since the DeltaX and DeltaY already are a form of "look up previous data" type compression. So it basically is performing multiple compressions, rather than a simple single compression. Then to make the complexity worse, parts of it are handled as whole bytes, other parts are handled as nibbles, yet other parts are handled as single bits. And even other parts are handled as words (pairs of bytes). And to further complicate things, some parts are handled as different sized data units at different steps in the process.


This makes the whole compression scheme overly complicated. And if you want to even DREAM OF writing a COMPRESSER for this, the analysis that the compressor software would have to do to perform the action of compressing the image would be so INSANELY COMPLICATED that the compression algorithm is basically IMPOSSIBLE to reverse engineer from the decompressor algorithm unless you are a SUPER GENIUS SOFTWARE ENGINEER!

I thought I could make a compressor after figuring out the decompressor. But nope. I've written a VB6 implementation of the decompressor, but I'm no closer now to writing a compressor for this format than before I was before. I was hoping someone maybe could help out with that, but I doubt it given the complexity of the compression scheme. I'd basically have to find the Japanese guy who invented the compression and hope he would be willing to give me the official specs on his compressor.

Ben321
Posts: 39
Joined: Fri Jul 30, 2010 8:05 am

Re: MAKIchan image format?

Post by Ben321 » Thu Jan 10, 2013 5:56 am

I finally wrote a successful MAG image file decoder in VB6, thanks to the specs provided here by Mimulus. The source code is in a zip file attached to this message.
The first line defines the constant FName has the file name (it requires the full path c:\etc...) to the mag image file. This isn't suitable in its current form for compiling as there's no way to select an image file to load at runtime (it's a constant set at design-time), but you can easily run it from the VB6 IDE as-is. Also this could be a building block for a project that is a full fledged mag viewer, or it could be used as a way to implement MAG format images in a computer game if you are writing a computer game in VB6.

The program as it is now, when run it does a number of things.
First if verifies that the path specified by the constant FName is valid. If this fails, the program quits.
(it doesn't yet check the file extension, so you could use a Makichan2 format image with a different extension like .XYZ instead of .MAG, and it would still load, but I may add file extension checking in a later version).

Then it loads the file.
The first thing it does after loading is it checks the first 6 bytes of the file to make sure they contain the string "MAKI02". If this check fails, the program quits.

If it passes these checks, it then procedes to parse the header and other data in the file and display the image, as well as in another box it displays the info provided in byte 4 of the header (the "screen mode" byte). This includes the number of colors in the palette (8, 16, or 256), the number of lines on the display that was the type of display that the image was intended to be viewed on (200 or 400), and whether the dispalay that the image was intended to be viewed on was an "analog" or "digital" display (except for the palette, these other infos seem useless, pretty much just meta data about the type of display that the artist who created the image expected it to appear best on). Also this image info box displays the width and height of the image.

This program also properly handles nonstandard image sizes. Typically a MAG image is supposed to have widths that are multiples of 8 pixels. If this isn't the case it originally caused my program to crash. I have created a workaround where the image (if its width isn't a multiple of 8 pixels) is padded to such a multiple during decompression and then prior to display the padding is removed so that it has the correct image width as stated in the header of the file. The next best program for this is Fine-View (it has the ability to do both loading and saving in MAG format) does pad it so it will decompress properly, but then it fails to remove that padding, and as such the image will have a black bar on the right side if it isn't an exact multiple of 8 pixels in width. My program doesn't make this mistake.
Attachments
MAG Viewer.zip
(3.33 KiB) Downloaded 106 times

User avatar
xnview
Author of XnView
Posts: 31747
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: MAKIchan image format?

Post by xnview » Fri Jan 11, 2013 10:46 am

Thanks, i'll check your viewer
Pierre.

Post Reply