| |
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
|
|
... 23 posts hidden. Click here to view all posts....
|
| |
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 |
| Previous - 1 | 2 | 3 | 4 - Next |
