Closed GoogleCodeExporter closed 9 years ago
GoogleCodeExporter
commented
9 years ago That sounds incredibly entertaining to do, actually. I'll have to get through
all the slog work on 3.0 first though.
Also, some sample files would help a lot.Original comment by paracel...@gmail.com on 3 Oct 2012 at 10:04
GoogleCodeExporter
commented
9 years ago Here it is. Some sample files in Maki-chan format.Original comment by schmid...@gmail.com on 4 Oct 2012 at 1:19
Attachments:
GoogleCodeExporter
commented
9 years ago More Maki-chan files can be found here:
http://www.msxarchive.nl/pub/msx/graphics/mag
Warning: These ones are NSFW.
Original comment by schmid...@gmail.com on 4 Oct 2012 at 1:49
GoogleCodeExporter
commented
9 years ago Implemented! Now correctly loads all of those pictures, except for AHGD0006.LZH
which I can't seem to unpack. Is it broken, or is The Unarchiver broken?
Also, that doesn't seem to include any 8 or 256 colour pictures. Those are
implemented, but completely untested.
Are there any more example files around?Original comment by paracel...@gmail.com on 2 Dec 2012 at 2:04
GoogleCodeExporter
commented
9 years ago Those are all files I have. I asked for more files on this forum post, maybe
someone on the MSX community has some more:
http://www.msx.org/forum/msx-talk/general-discussion/where-find-maki-chan-files
I'm sure people from Japan have a lot more files, but it's hard to find since
all their sites are on Japanese language.
I also created a magic file for the /bin/file command. It can help you to check
the header decoding against your implementation:
# Maki-chan Graphic format
0 string MAKI02\ \ Maki-chan image,
>8 byte x system ID: %c
>9 byte x \b%c
>10 byte x \b%c
>11 byte x \b%c,
>13 search/0x200 \x1A
>>&8 uleshort+1 x %dx
>>&10 uleshort+1 x \b%d,
>>&3 ubyte&0x82 0x80 256 colors
>>&3 ubyte&0x82 0x00 16 colors
>>&3 ubyte&0x82 0x01 8 colors
>>&3 ubyte&0x04 4 digital
>>&3 ubyte&0x04 0 analog
>>&3 ubyte&0x01 1 \b, 2:1 dot aspect ratio
Original comment by schmid...@gmail.com on 2 Dec 2012 at 5:17
GoogleCodeExporter
commented
9 years ago [deleted comment]BTW, I really would like to thank you for implementing this! :)
Is there a beta available for us to test?
Original comment by schmid...@gmail.com on 2 Dec 2012 at 5:21
GoogleCodeExporter
commented
9 years ago
Here it is: i've got some more MAG files on attachment. :)
umaiboux from the MSX community also helped providing many links for MAG files:
http://www.ateliermw.com/cglib/ewakalst0001.html
http://www.ateliermw.com/cglib/ewakalst0101.html
http://www.ateliermw.com/cglib/ewakalst0201.html
http://www.ateliermw.com/cglib/ewakalst0301.html
http://miko3.jp/cg/cg_osy1.html
http://www.ateliermw.com/cglib/
Original comment by schmid...@gmail.com on 3 Dec 2012 at 7:27
Attachments:
GoogleCodeExporter
commented
9 years ago Oh, good. Some of these definitely don't work. I'll look into fixing that once
I am done with some other stuff.Original comment by paracel...@gmail.com on 3 Dec 2012 at 7:58
GoogleCodeExporter
commented
9 years ago Does OYUMI17.MAG work at all? It seems corrupted, but I am not sure if it's
just some weird variation that I don't have support for.Original comment by paracel...@gmail.com on 6 Dec 2012 at 5:21
GoogleCodeExporter
commented
9 years ago Never mind, got OYUMI17 to load after all.Original comment by paracel...@gmail.com on 6 Dec 2012 at 6:34
GoogleCodeExporter
commented
9 years ago All right, I think I have managed to get all the .MAG and .MAX files from there
to load correctly now.
I also got a bit carried away and implemented the older MKI version. The only
sample files I got for that were the ones off ateliermw.com though.Original comment by paracel...@gmail.com on 7 Dec 2012 at 12:27
GoogleCodeExporter
commented
9 years ago Very cool, thanks! When will we have a Beta for testing this nice feature?
:)
If you liked the japanese image formats, there's also the japanese .PIC format,
which was used on the Sharp X68000 computers (32K colors). As with MAG, there
are some nice images in this format. I can open a specific Issue for that, with
files and some (jp) docs if you get interested.
Original comment by schmid...@gmail.com on 7 Dec 2012 at 12:47
GoogleCodeExporter
commented
9 years ago Well, as a late christmas present, here is the first version I feel at all like
showing to anybody:
http://code.google.com/p/xee/downloads/detail?name=Xee3_1.0alpha4.zip
Warning: This is nowhere near finished. Huge amounts of functionality from 2.x
is missing completely. It is also heavily using GPU tricks, and has only been
tested on a new Air. It probably requires a fairly beefy GPU to run smoothly,
as I have not yet put in fallbacks for weaker graphics chips.
Also, it requires 10.7.
But you can enjoy the Makichan loading, and the super slick image scaling.
(Make sure to enable the "Show Pixels" option, then try gesture zooming, or
shift and + or -.)
Original comment by paracel...@gmail.com on 26 Dec 2012 at 10:58
GoogleCodeExporter
commented
9 years ago Hi!
I just tested it (after an upgrade from Snow Leopard to Mt Lion just for that)
and this Xee3 v1.0alpha4 works great! It did read all MAG/MAX files I thrown
into it. Awesome!
If you're interested, there's a more advanced method for decoding YJK/YAE
images that results in a much improved visual. You can read more about this on
the following link. It's quite easy to implement, since only an additional step
is needed before the chroma conversion. Please feel free to ask if you have any
questions.
http://www.msx.org/forum/msx-talk/software/enhanced-decoding-yjk-images
It could be implemented as the default algorithm for decoding YJK/YAE files,
with a configuration option to select between the enhanced or classic decoder.
Original comment by schmid...@gmail.com on 31 Dec 2012 at 5:52
GoogleCodeExporter
commented
9 years ago I did some additional tests, and it seems that the YJK/YAE system was really
designed to take advantage of the NTSC decoder circuit built-in on all TV
receivers to do the needed chroma interpolation and so eliminate/minimize
jagged borders and generate a lot more perceived colors.
Without this interpolation, the number of simultaneous perceived colors is
reduced to only 10% of what an MSX connected to the TV via S-Video would be
capable to display. The digital system is capable of representing 19268 colors,
but the analog chroma interpolation increases this buy a tenfold! It was an
incredibly nifty design to use the NTSC decoder in such way.
This means that interpolation of the J and K data is an important step to
recover the complete color information that the real MSX2+ system would be able
to produce. Maybe you can put a preference setting to allow the user to select
the desired chroma decoder algorithm between: flat, Cubic interpolation or
Lanczos3 (from worst to best).
You can see the results for yourself on this thread:
http://www.msx.org/forum/msx-talk/software/enhanced-decoding-yjk-images
BTW, thanks for implementing the Maki-Chan format! :D
Original comment by schmid...@gmail.com on 11 Mar 2013 at 3:35
GoogleCodeExporter
commented
9 years ago There's probably not a noticable difference in speed, so there's probably no
need for any options. I might add interpolation at some point.Original comment by paracel...@gmail.com on 11 Mar 2013 at 11:52
GoogleCodeExporter
commented
9 years ago It would be interesting to have at least two types of decoding, as it would
cover the two possible use cases:
1) "Lanczos3 chroma decoding" is more appropriate for the "General User
importing pictures" use case, where the resulting image quality is the most
relevant requisite;
2) "Flat chroma decoding" is more appropriate for the "Cross-development" use
case, where obtaining the image with the raw values contained on the file is
the most relevant requisite;
The default decoder could be Lanczos3, as it would be better for the vast
majority of users.
Original comment by schmid...@gmail.com on 11 Mar 2013 at 6:47
GoogleCodeExporter
commented
9 years ago
Another idea for a better YJK decoding is to expand the J, K and Y to 8bit each
before applying the Lanczos3 interpolation. This will result much more precise
chroma reconstruction for the R and G channels, and in 8bit/channel color
values for those two channels.
Of course the divisors in the Blue channel formula will have to be adjusted to
reflect this expansion.
After decoding the entire image as 24-bit, the chroma of the red and green
channels will have been properly reconstructed with smooth transitions. But the
chroma for the blue channel need be reconstructed with some additional steps:
1) Decode the image into YCbCr using the BT.709 formula
(http://en.wikipedia.org/wiki/YCbCr#ITU-R_BT.709_conversion)
2) Apply low pass filter on the Cb (blue chroma) channel (can be a linear
selective gaussian blur, i.e.). That will provide the same kind of blue chroma
interpolation that the S-Video signal provides on the real MSX.
3) Encode the image again to RGB using the BT.709 formulas.
Original comment by schmid...@gmail.com on 5 Jul 2013 at 10:29
GoogleCodeExporter
commented
9 years ago Tip:
Xee3's feature page ( http://xee.c3.cx/features ) mentions "MSX MAG and MKI
files" support, but people will find your software better while googling if you
mention "Japanese Maki-chan (MAG, MAX & MKI)" file format support. As this
format was used by many japanese computers like MSX, Sharp X68000 and NEC PC-98.
Original comment by schmid...@gmail.com on 12 Aug 2013 at 10:10
GoogleCodeExporter
commented
9 years ago There are many MAKICHAN files in the following website, and some of them crash
the Xee MAG loader.
http://smcnet.ddo.jp/mmm/pool/CG/
Original comment by schmid...@gmail.com on 14 Sep 2013 at 2:03
Original issue reported on code.google.com by
schmid...@gmail.comon 3 Oct 2012 at 9:47