Look for downloads on external sites:
Submitted by apprentix on 15 January 2023
|Thanks for Linux support.
Submitted by Wile Coyote on 2 January 2022
|If this tool receives further upgrades in the future, how about an option to add a .sid and save an .exe
Submitted by KAL_123 on 2 January 2022
|Superb tool, i used it alot in last months for converting pics. Really good!
Submitted by Lubber on 2 July 2016
|very interesting last SVN commit messages ..:)
Submitted by ThunderBlade on 9 March 2016
|Kudos to Bitbreaker and of course Deekay for this fantastic work!
Submitted by Urban Space Cowboy on 26 June 2014
|svn repository wants a username and password now, please fix it or tell us peons what login creds to use
Submitted by Repose on 7 May 2012
|I've found the algorithm to directly compute optimal FLI colors. Haven't tried to integrate sprite layer though. Has anyone else discovered this?
Submitted by DeeKay on 12 May 2011
|Daily snapshot of the latest Mufflon (featuring lots of goodies, new YUV/HSL mode, floyd/error diffusion dithering instead of pattern, lots of extra sliders for image adjustment and OpenMP multithreading for up to six cores!) available now for public via:
svn co https://svn.sngs.de/metalvotze/svn/repo/mufflon
Requires installed Subversion client (well, obviously), Python, PIL, TCL/TK (for the GUI, already installed when you got Mufflon 1.0 (Linux) running) and OpenMPI (for multithreading)! Beware! This is probably pretty much Unix-only, Windows branch hasn't been worked on since v1.0!
Submitted by DeeKay on 14 February 2011
|Just for funsies as a proof of concept: Here's Mufflon (ARMEL) running on a WM8505-based 100 Euro ARM-Mini-Netbook (300 MHz, 128MB RAM, 7.2", 800x480, Ubuntu):
(That's an eeePC 10" it's standing on! And no, i can't reach the Convert button at this resolution! ;-)
Thanks to Streetuff for all the help getting there!...
Submitted by DeeKay on 3 November 2010
|NUFLI Editor V1.12 is released... Use that instead of the old one included here to make NTSC users happy! ;-)
Submitted by DeeKay on 22 October 2010
|Exin: please read the readme, it clearly says what this was designed for, also how the mapping to c64 color gradient works. And no, it was not designed only to convert IFLIs and Drazlaces, it was designed for 320x200x16 pictures pixelled in whatever floats your boat! ;-)
Submitted by Exin64 on 12 October 2010
|looks ok for converting interlaced C64 pictures to nufli. For everything else, there are important things missing, like intelligent color detection. (I tried to convert a picture, the skin was way too bright, when i turned down the luminace a bit, the eyes turned green, where white should have been)...
Submitted by Rayne on 15 September 2010
|I'm missing a version running native on the 64!
Submitted by chatGPZ on 2 September 2010
|"and Crossbow uses Windows..."
yet he doesnt have a compiler it seems.... =P
Submitted by tempest on 20 August 2010
|Fantastic release. Thumbs up.
Submitted by DeeKay on 20 August 2010
|Frantik: Anything else would've been embarassing! ;-D But it came kinda naturally, since Bitbreaker uses Ubuntu, I use OSX (mainly) and Crossbow uses Windows..
Soon to come: Finally an i386 deb and one for S/390, so you can also run Mufflon on your IBM mainframe! 8))))
Submitted by Frantic on 19 August 2010
|You guys must admit.. This is kinda funny. First Deekay whines for 55 years here on CSDb about the lack of multi platform support in various tools. ...and then he + colleagues score nicely with downloadable binaries for a zillion of platforms. Haha... Thumbs up to mr Deekay, I have to say.
Submitted by Digger on 19 August 2010
|Hell yeah! And there's OS X version as well! Schweet! ;-) Bitbreaker and Mr Sid are the men! And Deekay and XBow as well.
Submitted by DeeKay on 18 August 2010
|We're just building a nice single-click deb-package for linux users, with icon and a direct entry in the program menu to the GUI! ;-) Will be added soonish, stay tuned!
Submitted by algorithm on 16 August 2010
|@bitbreaker. Absolutely, A routine which takes into account previous colors would take too much processing time. Example $d021 splits in FLI. Having to brute force each block per 8 vertical lines while having to go through permutations of testing $d021 colors per line and each 8 lines would give a huge amount of combinations just for $d021 alone etc but ofcourse having fli per 2 lines and sprite color splits at offset 1 line to the FLI makes it even more processor intensive
I have experimented in genetic mutation methods but this is suboptimal, but yes a tradeoff is certainly required unless we all of a sudden have 100ghz+ machines.
Yes certainly would be better to get the most out of the cores if wanting to see the results of one picture as soon as possible.
I had waited around an hour, could be just the pc glitching up or software conflict. Did anyone else have the same problem. It would also be a good idea to put the routine on a seperate thread as losing non focus on the GUI makes it freeze until it has finished processing.
Submitted by Bitbreaker on 16 August 2010
yes, in general it is a pain in the ass that one has to use the brute force way to solve this problem. And still, the algorithm is not getting the optimum out of it. How ever the fact that sprite color changes in odd and ink/paper in even lines forced me to make some trade-offs, as else each line would theoretically, depending on its result, influence all following/previous lines. This all can really make your head explode. I discussed the problem already with some colleagues at my faculty, but not much new ideas came up. I might try however a more memory consuming attempt with building up trees. Also wavelet-strategies + filtering might be an option, but not too familiar with that stuff, and if it could work.
Optimizing by using more cores or CPU-power will of course work, but i'd more likely would see better algorithms that are faster + delivery even better results.
@rest: And yes, some of the said feature requests are already on our todo-list/partly implemented (brightness/contrast/hue/saturation/more and intelligent target related dithering, ...) Hang on another 2 years or so, or participate :-)
Submitted by DeeKay on 16 August 2010
|isildur: err - could you please try the min/max luma sliders, at least for brightness and contrast! ;-)
algo: the Mac-GUI uses multithreading for batch processing. This is good, but multithreading NUFLI conversion on the single-image level would be better and would help more people! ;-) Up to six cores could be supported!
As for speed: I just tried radialgradient.bmp in MUIFLI with all switches (--anything-goes -b -d) turned on, took 1055 sec (17.5 minutes) on one core of my AthlonX2 4800+ (2.4GHz) with Ubuntu 10.04 64bit... Fast enough! ;-D
Submitted by Isildur on 16 August 2010
|Also Brightness/Contrast and Hue/Saturation would be great.
Submitted by algorithm on 15 August 2010
|Not too familiar on implementing assembly using C compiler. But yes Multithreading would be the easiest method (or to convert two pictures using two program instances on dual core :-))
Progress bar would be ideal however, How long does it take using all settings active (MUIFLI>=) (eg seperate ink/paper) I had it running for one hour but closed it afterwards. Each core of the cpu (athlonfx) is around 2.7ghz
Submitted by DeeKay on 15 August 2010
|algo: well, feel free to participate to implement all that! ;-) Subversion logins are available for anyone interested! 8) Please do read the license though first...
Though I'd rather multithread it before going assembly, probably much easier, low hanging fruit and all.. Much speedup can be gained on multicore machines (=pretty much everything these days)... the column-based nufli pretty much begs to be multithreaded! ;-)
Submitted by algorithm on 15 August 2010
|Finally released! Glad that some of the earlier bugs have been fixed. A few options such as the below would be great.
Ability to chose the amount of mix colors at the expense of more/less flicker
Assember optimisations (Brute force as usual with many factors takes a long time) mmx optimisations etc (although at the expense of some accuracy) would give a speed increase of 3fold+
The truecolor prep is great in the way that it reduces flicker by using more familiar shades. but an option to prep the data (with dither) using the 79 or so mix colors would be a good addition (I believe this is used when the 'prepare' truecolor option is not used, but does not dither the image
Overall a great tool.
Now time for me to perhaps release mine (but tempted not to until demo is finished) :-(
Submitted by Nitro on 15 August 2010
|Milestone release, the CLI works nicely but the GUI gives this error:
'UnicodeEncodeError: 'ascii' codec can't encode character u'\u017c' in position 10: ordinal not in range(128)'
I'm using Polish Windows 7 Professional.
Some other Polish sceners also reported that the GUI isn't working on their computes.
Got it working via launching by Python 2.6 + PIL. If it isn't working for you just download&install these, Mufflon1.0-source+GUI+Bonus and win32 binary, place binary in the mufflon-source+GUI folder, then just click on the mufflongui.py
Submitted by Conjuror on 15 August 2010
|Thanks guys, this is just in time. With my demo plans in tatters, at least I'll be a able to release my picture.
Submitted by DeeKay on 15 August 2010
|Lubber: that's exactly why we implemented the flickermap! ;-) but yes, an actually flickering AniGIF- preview would be even better... but someone would have to code that! 8) Feel free to, subversion logins are available upon request (-> Bitbreaker) ;-D
Submitted by chatGPZ on 15 August 2010
|"The problem is that now everyone will start using this and will forget the beauty of the multicolor"
i very much doubt that. people get tired of converted pics quickly, and it still takes a damn fine artist to do something original with this.
Submitted by Lubber on 15 August 2010
|Great stuff! Maybe it's an idea to show an animated gif from the result of a MUIFLI Picture. Because of the colormixing (instead of dithering) the result looks a bit better on the first look than the nufli within the GUI. So just anybody will actually see the difference directly at converting time and "show" the flickering.
Submitted by TomoAlien on 15 August 2010
|Awesome! I've been waiting for this!
The problem is that now everyone will start using this and will forget the beauty of the multicolor.
Anyways this deserves a perfect 10 from me. Also someone rated this 3/10.
Submitted by Almighty God on 15 August 2010
|Great stuff guys, thanxs a lot for this tool
Submitted by STE'86 on 14 August 2010
|Hmm well done but i think u missed "Key Grip, Best Boy and 2nd Assistant Dolly Operator" from the credits
Submitted by The Shadow on 14 August 2010
Submitted by Wile Coyote on 14 August 2010
|Now that Mufflon is complete, does that mean Meet Crest will be completed :D
Submitted by leonofsgr on 14 August 2010
Submitted by Zeldin on 14 August 2010
Submitted by Joe on 14 August 2010
"Who controls the past
controls the future
Who controls the present
controls the past"
Submitted by Deev on 14 August 2010
|great to see this released! just at the right time for me as well ;)
Submitted by Hermit on 14 August 2010
|I'm really glad to see this released! A new major step in C64 scene's history.
Submitted by grennouille on 14 August 2010
|I love this tool! Thank you!
Submitted by DeeKay on 14 August 2010
|I can't either! ;-D It's been a fucking shitload of work.... Almost 2 years now, you were right, Oswald! 8)
Don't forget to grab the Bonuspack as well if you want to play around with it!
Submitted by WVL on 14 August 2010
|Can't believe it's actually released :)
· Hidden Parts