| |
DeeKay
Registered: Nov 2002
Posts: 362 |
This is the Thread for everything NUFLI!
The Era of NUFLI has begun - Bye Bye Interlace!
So what do you guys think? 8)
btw. Until Bitbreaker decides the converter is fit for release, you may send me your pictures and I'll put them through it. No, I won't fix the bugs for you (been doing that for over a hundred hours in the recent months! <:-), you gotta learn your way around the editor eventually if you want that extra edge of perfection - But I will offer some advice on different approaches how to combat teh blockiness or teh color lack, i even prepared some tutorials I will post here later! ;-)
Please do keep in mind that even in NUFLI, you still only have 3 colors horizontally in every char -with one fixed for 6 chars- (5 or 6 in the FLIbug, but that's for all 3 chars!). Considering that IFLI has a maximum of 6 colors in one char, it's quite surprising the pictures in the Slideshow come over so well, but apparently most people don't use IFLIs capabilities to the full extent - and then there's the horizontal PAL colorblur, which means many different colors don't actually make so much sense after all, since you can't distinguish all the colors so well anyway! |
|
... 160 posts hidden. Click here to view all posts....
|
| |
Carrion
Registered: Feb 2009
Posts: 317 |
Algarbi:
Maybe it looks easy for the first sight (I also though it'll be easy to fix after the coversion) but belive me the limitations You have with NUFLIs (especialyy Sprite color in my opinion) makes it not so easy work.
Withou help from DK I'd probably stuck with some parts of my images.
Actually most of fixes in my pictures were done by our NUFLI master :)
|
| |
Carrion
Registered: Feb 2009
Posts: 317 |
OK So here's a example which I think maybe some people were thinking about:
Sorry for different saturations on images but you get the point.
one more saturated is original, second is straight convert without fixing.
enjoy ;)
 |
| |
algorithm
Registered: May 2002
Posts: 702 |
Perceptual Brute force would solve the issue with color selection. The lower the perceptual error, the lower the visible error. Pixels of similar intensity/luma would share the same color freeing the color for a pixel that is different in brightness or luma |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Algo: Ofcourse we do have luma-weighting in there, do you think we're morons? <:-) the whole thing is computed in YUV, and colors with similar Y are the first to go...
Still, for some reason, the converter still does it sometimes. I think it's a special case in combination with spritecolors or sth... |
| |
algorithm
Registered: May 2002
Posts: 702 |
Could just be a bug or how the routine works that is causing the problem.
A brute force routine based on hires with x expanded hires sprite underlay would be something as follows. Using this method. it should solve the problem
spritecol=0
inkcol=0
papercol=0
loop1:
compare inkcol to pixel1 and compare difference
compare papercol to pixel 1 and compare difference
use least different and plot to pixel1 buffer1
compare inkcol to pixel2 and compare difference
compare papercol to pixel 2 and compare difference
use least different and plot to pixel2 buffer1
compare inkcol to pixel1 and compare difference
compare spritecol to pixel 1 and compare difference
use least different and plot to pixel1 buffer2
compare inkcol to pixel2 and compare difference
compare spritecol to pixel 2 and compare difference
use least different and plot to pixel2 buffer2
compare buffer1 and buffer2 to original 2x1 section of c64 16 color image and plot the 2x1 block with least difference to the required area in buffer3
repeat till 8x8 block is complete
compare 8x8 pixel area in buffer3 with 8x8 section of c64 16 color image and note difference
increment papercolor and go to loop1 till papercolor=16
increment ink color and go to loop1 till ink color=16
use ink/paper color that is the least different to original c64 8x8 block and plot to buffer4.
repeat process till all 1000 chars are complete
compare entire image in buffer 4 to c64 16 color image and note error value
increment spritecol by 1 and go to loop1 till spritecol=16
use spritecolor that gives the least error value and then render the image
The above is a very basic example just from the top of my head. ofcourse optimisations can be 10fold. eg no need to have same paper/sprite color as you cant have paper and spritecol together etc etc
|
| |
Jetboy
Registered: Jul 2006
Posts: 213 |
Wouldnt taking into account all combinations of charcters, sprites and all possible color changes throughout entire image in case of NUFLI make computations long enough to take years for one picture? |
| |
algorithm
Registered: May 2002
Posts: 702 |
Not at all. You would only need to work in smaller slices. eg 8x2 rather than 8x8 etc.
The above routine optimised would take a few seconds to complete. The MUCSU routine takes around 20 minutes on a 1.8ghz machine (Brute force) but that goes through every single multicolor sprite combination rather than mono 16.
Ofcourse if you want to involve sprite x shifting, multicolor/hires toggle for individual sprites in specific area's etc to minimize errors et then it would then take an extremely long time |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quote: Algo: Ofcourse we do have luma-weighting in there, do you think we're morons? <:-) the whole thing is computed in YUV, and colors with similar Y are the first to go...
Still, for some reason, the converter still does it sometimes. I think it's a special case in combination with spritecolors or sth...
Care you show us (well, me.. ;) the precise formula and coefficients you guys came up with for the RGB (pr0n) images?
I've experimented with fancy color matching methods taking the relative luminance of the channels and gamma correction into account, but no matter how I tweak it a straight RGB mean-square-error comparison always just seems to look better.
I'd love to have a way of automatically generating fades with anything remotely resembling the quality of hand-tweaked tables. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
p1 goes into HSB space (hue-saturation-brightness)The solution was peeked from Mirage - to give proper credit. then you build your own hue-brightness lookup table by hand, and dither into a gray table if you want to take away saturation. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Actually the idea of using different colorspaces (YUV is rather popular, too) and then matching gradients is quite old... That's what the converter does as well when "prepping" a picture. Works quite nicely, let me post an example pic...
Algo: I should tell you from Bitbreaker that he already does what you do, only way more efficiently and sophisticated! ;-)
It's not like he coughed up that converter in one night, there was much much much trial and error involved, for the NUFLI version he even re-did the whole thing to make it colum-based (six picture sprite columns, one AFLI column (40th char), one flibug column) rather than line-based like before!
Depending on the picture, the converter now takes something like a few SECONDS to render it on one Core of my Quad 2.5 GHz G5!...
Conversion-progress:
--------------------
Processing normal colums: Pr0ncessing line #198 on colum 5
Processing colum 39: Pr0ncessing line #198
Processing fli bug: Pr0ncessing line #198 -1 -2 -2 -2
Maxerror per pixel: 255
Overall error: 0.43%
Erroneous pixels 2784
Writing 'train_v1_errormap.bmp'
Writing 'train_v1_result.bmp'
Writing 'train_v1 .nuf'
calc.time: 8.6370s
(This is Carrion's train!) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 17 - Next |
