| |
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....
|
| |
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: 5027 |
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!) |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Here's a prepped example pic from a truecolor photograph i took in Cambodia:
Keep in mind that this is in interlaced colors and that it hasn't gone through the converter yet, it's just how it renders a picture in c64 colors! |
| |
algorithm
Registered: May 2002
Posts: 702 |
Deekay. The description of the routine was only based on the most basic example (standard hires and multicolor underlay) I admit the converter code was done in an hour or so.
The point i was making was that with such a mode with far less limitations than standard hires (NUFLI, MUFLI), why there was a substantial amount of errors. I am not trying to put anyone down here. just a constructive critism. I have displayed the wolverine picture converted into plain hires and underlay for comparison and ofcourse the MUFLI/NUFLI version is more defined for the very colorful image, but with two colors every 8x2 in the FLI mode combined with sprite color changes i was expecting less errors without the need to touch up the pictures that much
Ofcourse there is more work to convert to the NUFLI/MUFLI mode. but with the color limitation being lifted, the mode has the capability of displaying with less visible errors
Below is the direct conversion in standard hires and underlay (MUCSU) without any touches to the image
And below this is the NUFLI conversion without any touches
With such a mode able to have 2 different colors per 8x2 and sprite color changes but looking very similar to standard hires with underlay, is it wrong for me to not try to give some critism. Like I said, I only discussed that there must be a possible bug in the conversion routine of the NUFLI converter or how the routine works |
| |
_V_
Account closed
Registered: Jan 2002
Posts: 124 |
>> The Era of NUFLI has begun - Bye Bye Interlace!
Well, as I posted in the picture demo thread, interlace does have its merits. Not when you're throwing tons of white in there, but you can sure get some nice glows with the darker tints.
>> 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-
What? No total freedom? And I was so looking forward to plotting an eight colour gradient in a single line of each character! Seriously though, thanks for sharing the restrictions, that helps planning the colouring of my Pokémon conversions...
Will say thanks for this new mode. Fullscreen lotsa flexible colours no interlace is always very, very nice.
Cheers,
Vincent.
PS: By the way, DeeKay, how do the fullscreen IFLI pictures from Krestology hold up after conversion? I kinda hoped for/expected them to pop up in the demo...
-- La vie, c'est la guerre des dualités. |
| |
algorithm
Registered: May 2002
Posts: 702 |
Quote: >> The Era of NUFLI has begun - Bye Bye Interlace!
Well, as I posted in the picture demo thread, interlace does have its merits. Not when you're throwing tons of white in there, but you can sure get some nice glows with the darker tints.
>> 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-
What? No total freedom? And I was so looking forward to plotting an eight colour gradient in a single line of each character! Seriously though, thanks for sharing the restrictions, that helps planning the colouring of my Pokémon conversions...
Will say thanks for this new mode. Fullscreen lotsa flexible colours no interlace is always very, very nice.
Cheers,
Vincent.
PS: By the way, DeeKay, how do the fullscreen IFLI pictures from Krestology hold up after conversion? I kinda hoped for/expected them to pop up in the demo...
-- La vie, c'est la guerre des dualités.
Further to that. you cant use spritecolor and a papercolor in a 2x1 area at the same time as the spritepixel is 2x1 in size. only the ink color (at 1x1) can appear at any position |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Algo: There is no "bug". Two things:
1) You're using multicolor sprites, we use Hires. 4 colors in 8 pixel width vs 3. Like I said before, using MCol sprites in NUFLI should improve quality quite a bit more even!
2) Like I also said before: Your result is pretty much it, it doesn't get much better even with manual work, since you can only change color in a whole 8x8 block (fat chance the converter could not get THAT right!), set or unset bitmap pixels or set one of four colors as the background in a quarter char. that is it! With NUFLI I *can* fix the bugs (and I've NEVER encountered a bug I couldn't fix somehow!) because i have FLI in Bitmap and sprites!
Besides, NUFLI works for almost any picture, not just some selected ones... |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: Further to that. you cant use spritecolor and a papercolor in a 2x1 area at the same time as the spritepixel is 2x1 in size. only the ink color (at 1x1) can appear at any position
well, no shit, sherlock? 8)
UFLI is from 1996, dude... |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | ... | 18 - Next |
