| |
algorithm
Registered: May 2002
Posts: 705 |
Release id #40966 : MixCol Hi-Fli Converter 104
New version released
* Updated C64 display code. Shows more of the screen and covers the FLO bug on the left
* Saving Raw/.Prg when not utilising 4 mix colors will now result in the filesize taking up 24k rather than 32k
*GUI cleanup
* New Y Brightness color matching. This maps the brightness of a truecolor pixel to a c64 pixel of the same brightness. More colors are utilised this method. Turn monitor to black and white = tonnes of grayscales
* Flicker Filter Strengths. It is now possible to select filter strength. in both overall and additional 2 color mode.
* Updated Documentation and examples
|
|
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
couldnt it have some simpler name? this is so wannabee eighties style naming. :)
why not truecolor hires interlaced afli mixed lace color picture converter ? :PP :) |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
couldnt it have some simpler name? this is so wannabee eighties style naming. :)
why not truecolor hires interlaced advanced flexible line interpretation mixed lace color picture converter ? :PP :) |
| |
algorithm
Registered: May 2002
Posts: 705 |
That would be a great name!!! ;-) |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
well while playing with the converter I started thinking that you really made something, but the examples are not satisfying I'm sorry :( The converter code is very well done, but the mix colors doesnt come through -> the results are not nice. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11354 |
works in wine (just thought i mention it)
anyway, i'm not really impressed either.... its okish, but nothing spectacular. |
| |
Monte Carlos
Registered: Jun 2004
Posts: 358 |
I've got some reasonable results with a jpg. picture conataining smooth transitions. (How do i insert the jpg. and the converted picture here?)
With another picture containing a yellow, purple, red and green colorclash i got miserable results. This was due missing
colors bright yellow and bright red in the color palette of the converter. So the stains got lightgreen instead of yellow, purple instead of red and brown instead of purple.
Monte
|
| |
algorithm
Registered: May 2002
Posts: 705 |
The color matching routine is still very basic at the moment. (RGB difference). To implement more advanced color matching. However problems with wrong color choices can be rectified using the sliders. Have a look at the following examples. - Using medium flicker reduction (Before and After).
Before
[/img]http://www.myfilehut.com/userfiles/106855/before.jpg[/img]
After
[/img]http://www.myfilehut.com/userfiles/106855/after.jpg[/img]
|
| |
algorithm
Registered: May 2002
Posts: 705 |
The color matching routine is still very basic at the moment. (RGB difference). To implement more advanced color matching. However problems with wrong color choices can be rectified using the sliders. Have a look at the following examples. - Using medium flicker reduction (Before and After).
Before
After
 |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
And if you hand pixel it manually you get:
http://noname.c64.org/csdb/release/viewpic.php?id=11066
One of Dane's masterpieces... |
| |
algorithm
Registered: May 2002
Posts: 705 |
yes, that XFLI picture is a lovely piece of pixelling. |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
my problem is the same as in the beginning: the mix colors doesnt look at all the same on the real thing like the ones on your screenshots |
| |
algorithm
Registered: May 2002
Posts: 705 |
Can you clarify that further?
Is there a major difference between PAL emulation in Winvice and a TV set. It looks fine in Winvice and on my TV Set.
What do the others think? Its just a bit funny how some people say that the conversion and display on a C64 looks amazing and some say it does not??
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11354 |
oswald is ignoring the fact that every c64/monitor combination looks different =) |
| |
Steppe
Registered: Jan 2002
Posts: 1510 |
You have to use a colour monitor, Oswald! Greenscale won't do no good here... ;-) |
| |
algorithm
Registered: May 2002
Posts: 705 |
New release... Ignore the build date. for some reason I thought it was the 14th
Changes as follows (including a major bug fix(
Major bug fix. If an image was loaded and converted(without changing the flicker filter to anything else) e.g. Default flicker mode, the image would look fine in the preview screen, but would have the wrong mix colors in most places (mainly black and white flicker colors) once run on a c64 or emulator. This was due to a c64 color not matching what was in the lookup table... Fixed.
Perceptual Color reduction mode. This drastically improves
the final quality of the conversion, but takes slightly longer to process. Now the default option. Colors match more closely to the mix color
Option of RGB or YUV mixed color palette conversion.
Reorganised GUI, many options are now in order rather than
being scattered around. New app pic.
Removed extra 2 color flicker filter. There was not much
point in this option as it would mainly result in edges of
objects flickering more than the rest.
Removed pre-processed mode. It is now possible to load either a jpeg or bitmap and decide whether to redither the image (if it is a pre-processed bitmap) or not
Error pixel percentage option. This basically tells you how much error is generated from the semi processed image (color matched and dithered) to the final c64 image (with AFLI limitations) Lower number generally mean less visible errors although that depends on where the errors are located.
Additional Low flicker filter option. Now default. Removes some wrong and extreme mix colors (e.g. white and black) but keeps the rest.
Generated mix color palette now displayed on screen.
Addition of 4 palettes (for use in Photoshop if required)
None, Low, Medium and High Filter |
| |
Jetboy
Registered: Jul 2006
Posts: 292 |
I just wonder.
You said you take 2 colors and mix them into 4 colors.
As far as i understand it you can get only 3 colors from mixing. Lets take white and black for example. If you mix
white+white=white
black+black=black
But mixing white+black and black+white result in the same colour. Yes they flicer in counterphase, but the mixed color is the same.
Or m'i missung something?
|
| |
algorithm
Registered: May 2002
Posts: 705 |
Noo. This is how it works
Possible combinations
Ink layer1, Ink Layer 2
Paper layer1, Paper Layer2
Ink Layer1, Paper Layer 2
Paper Layer1, Ink Layer 2
4 Colors
|
| |
algorithm
Registered: May 2002
Posts: 705 |
of course it depends on the colors in the ink1,paper1,ink2,paper2 layers. in some cases it will not be possible to have 4 different colors. The brute force perceptual routine will look at all combinations and recalculate the additional 2 mix colors, then perceptually compare it to the original dithered 8x1 line.
Most similar match will result in the colors being mapped into the ink and paper for layers one and two |
| |
algorithm
Registered: May 2002
Posts: 705 |
New version released. Many changes and additions including ability to change color palette and Non interlaced HIFLI conversion |
| |
Copyfault
Registered: Dec 2001
Posts: 475 |
Wondering about that Alternate X8-Mode... what does this do? If I got it right it alternates Charcolumns after the conversion process... maybe smth else???
Speaking of "alternate X": wouldn't linewise X-shifting be of some use for this convertor? It would give some more colour combinations (not bound to the char width), but conversion routine would become rather difficult. Had some knots of this kind in my head a while ago when thinking about a convertor for ILM :( Unfortunatly I didn't come up with a neat solution up to know.
CF |
| |
algorithm
Registered: May 2002
Posts: 705 |
Yes, the X8 mode is alternate characters horizontally.
The idea of shifting $d016 4 pixels to the right would allow more colors to be put into a char, but would also give the limitation of having to use the same ink& paper for half of the next character on (for example) the second layer
eg
Attribute window
EFEFEFEF
CDCDGHGH
Layer1
ABABABABEFEFEFEF
Layer 2
CDCDCDCDGHGHGHGH
|
| |
Copyfault
Registered: Dec 2001
Posts: 475 |
Yes, but there's no reason to choose a fixed $d016-shift of 4 pixels. A very rough idea for a brute force algo would be to check for each rasterline what are the best colours with the least error percentage and repeat this check for every xshift_val from 0 to 7. This may result in different xshift_vals for every line, but for sure also in more interlace colour combinations.
CF |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
the turn disk picture of void/resource uses exactly this technique. laced afli with changing d016 (always using the best shift value)
Void |
| |
algorithm
Registered: May 2002
Posts: 705 |
X1 interlacing can also be done. It only requires every second pixel of the dithered data to be swapped over.
The HIFLI reduction can then continue as normal. quality may be effected though as there may be more colors to reduce in a 8x1 area
Next on the agenda would most definately be sprites (1 layer unexpanded) on each layer
|
| |
algorithm
Registered: May 2002
Posts: 705 |
aaarrghhh!1 Wtf am i talking about. Too tired today. Ignore the previous post about x1 dithering |
| |
Copyfault
Registered: Dec 2001
Posts: 475 |
Quote: the turn disk picture of void/resource uses exactly this technique. laced afli with changing d016 (always using the best shift value)
Void
Hmm, now I understand why this laced AFLI_pic always gave me a special feeling when watching that demo ;))
So assuming the picture was converted, how was it done? Did you code any special converter back then? And what kind of algorithm sits behind this conversion?
CF |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
cant tell any details, the converter was done by janee/breeze, and it ran in dos. he told it uses brute force, and it picks a d016 value for each line so the line has the smallest error. I guess when he made the convert for us was the last time I spoke with him :-/ |
| |
Copyfault
Registered: Dec 2001
Posts: 475 |
@Oswald: THX for the info! Just if I didn't mention it before: the demo belongs to my favorites, not only due to this pic! More than two thumbs up!
Btw, is there any chance to get Janee back 2 C64_stuff? Or did he completely quit the scene?
CF |
| |
algorithm
Registered: May 2002
Posts: 705 |
New version released. Extra brute force mode and improved dither options.
C64 example..
http://www.naveedkhugiani.com/hifliint1%20-%20ordered.prg
|
| |
ptoing
Registered: Sep 2005
Posts: 271 |
That looks ok as far as displaying photos on the C64 goes, but what is the point really? When stuff like this is used in demos I have to cry. |
| |
Bamu®
Account closed
Registered: May 2005
Posts: 1332 |
This tool is F****** AWESOME! :) |
| |
algorithm
Registered: May 2002
Posts: 705 |
A lot of people dont like interlace modes, but without it, there is a huge limitation of colors. its possible to mix colors due to the blending of the pixels in pal, but under constaints.
I think as far as interlace flicker is concerned, the converter minimizes it due to the method of alternating the fields as well as the ability to choose which colors should be mixed, etc
Errors (between the dithered image and IAFLI converted image) can also be minimized by shifting $d016 per line to produce the least error or even using sprite overlays, UIFLI, etc etc. New converter on the horizon most definately. |
| |
Bamu®
Account closed
Registered: May 2005
Posts: 1332 |
Quote: A lot of people dont like interlace modes, but without it, there is a huge limitation of colors. its possible to mix colors due to the blending of the pixels in pal, but under constaints.
I think as far as interlace flicker is concerned, the converter minimizes it due to the method of alternating the fields as well as the ability to choose which colors should be mixed, etc
Errors (between the dithered image and IAFLI converted image) can also be minimized by shifting $d016 per line to produce the least error or even using sprite overlays, UIFLI, etc etc. New converter on the horizon most definately.
:-) |
