|  Post Your Message | |
| |
| | Previous Messages | Posted By
Csabo
on 2018-11-21
10:00:31
|  Re: DFLIConv2
That undocumented feature is actually very important and useful!
|
|
Posted By
bubis
on 2018-11-21
06:50:41
| Re: DFLIConv2
Well, that is not a coincidence. 
There is a feature I forgot to document too: if you set a color variable to a negative number (like -1) the converter will not use that color. For example: -r color3_000...color3_199=-1 for multi-dfli will not use color3 on the picture, so you can even have a soft sprite over the picture with different $ff16 values and it will cause no conflicts with the background. Also, fading in/out becomes easier if you set color0 to black as well.
|
|
Posted By
Mad
on 2018-11-20
23:38:52
| Re: DFLIConv2
WOW!! Awesome! This ultra customizable variable settings option (for colors,xshifts etc..) can be very useful when doing demos or games. Just played around with a temporary picture.. Pretty awesome stuff..
|
|
Posted By
bubis
on 2018-11-20
19:32:53
| Re: DFLIConv2
Hi!
V0.2 is out here: https://github.com/dotscha/dfliconv2/releases
It was a bit early to release this but I will not make any releases in the coming two weeks.
New:
- prg viewer for every default size modes, viewer source included
- you can load previous conversion results as a baseline (the re-touch workflow is not tested yet, I haven't documented it very well either for this reason)
- you can use custom badline settings for FLI (gfli)
- you can convert between supported formats of the same graphic mode
Please check README.md for further details.
Ok, so the re-touch workflow should look something like this. I tested it a little bit and it seems to work fine:
1. Convert your original:
dfliconv2 -m multi-dlfi -d bayer2x2 -i original.jpg -p
Now, you have original.prg and original_preview.png.
2. Edit the PNG preview and convert that(!) again importing the previous conversion as basaline and without(!) dithering:
dfliconv2 -m multi-dlfi -i original_preview.png -b original -o original_reconverted -p
This will output original_reconverted.prg and original_reconverted_preview.png, the conversion should run much faster and only the affected areas should change in the result.
3. Repeat (2) until not satisfied. :)
This should work with every other supported format of course, not just multi-dfli.
Hi,
V0.3 is released: https://github.com/dotscha/dfliconv2/releases
New features:
- custom palette option: -pal
- new dithering method: ord2x4
- new viewer for DFLI images: 'p4fli'
- create dithered image with Plus/4 colors without conversion
See more details in README.md.
|
|
Posted By
Chronos
on 2018-11-03
14:04:04
 | Re: DFLIConv2
♥♥♥ for the png support, and re-touch ability! ♥♥♥
|
|
Posted By
Sandor
on 2018-11-03
01:35:15
| Re: DFLIConv2
I think that if you want to get the maximum out of variable number of C/L values, you should do some preprocessing in YUV colorspace. Since the plus 4 colors have their UV values pretty close for the same C value, you can just find the best 2 UV values, remap your pixels into those while keeping the original Y values and then do the remapping using the shades of the colors of the best matching UV coordinates. Since the human brain is less sensitive to color resolution than to luma resoltuion, this might give us better perceptional results - even with some fixed CLLL or CLLLLLLL modes.
|
|
Posted By
MMS
on 2018-11-02
15:24:56
 | Re: DFLIConv2
Just an amateurish comment from my side:
Still the best thing is the human brain. If you leave those settings to the user, he can play wit that, and can fin dthe best setting.
Based on my experience, some setting work perfectly for some pictures, and the same will not work on other ones. So there is no perfect setting for all pictures. Eg. Larry usually adds noise to the pictures, because it works better with his conversion routine, while I remove them from the original photos, because Jarvis2 method does not like it.
Sometimes I like to play with settings even for 1-2 hours on a single picture, to make it best looking possible. I know it is not visible on all my releases ( frankly speaking I overused Plus4emu display quality settings, cheating myself on end-result) but still have some dozens of very good looking random conversions.B ecause I prefer tematic releases, they will be stored on my HDD for an undefined period.
But I really like tinkering on the settings, the more buttons I have, the more I like it
|
|
Posted By
Degauss
on 2018-11-02
08:41:27
| Re: DFLIConv2
2) I think you got it. A retouch-workflow would be something that every artist would be glad to have. Great Idea!
|
|
Posted By
bubis
on 2018-11-01
19:17:20
| Re: DFLIConv2
Hi,
1) As for "something more perceptive" I came across and now use the CIELab color space what was precisely design to measure color distance as humans percieve it. I don't know anything about pal color blending, that's a good point.
2) I am not sure this kind of overweighting would really work, I trust the CIELab color metrics now. What I would like to archive in this front is supporting a re-touch workflow: (1) conversion with PNG preview output (2) edit/fix the PNG (3) import the previous conversion and re-convert the changes made on the PNG. The key feature here is the ability to import a baseline before (re)conversion.
|
|
Posted By
Degauss
on 2018-11-01
12:35:32
| Re: DFLIConv2
you're right: its hard to believe CLCL is always the best way to go 
I didn't dig as deep as you did but my attempts with "adaptive" didn't show any benefit over the straight CLCL-config - at least for pictures i tested. I figured in the end i was only trading error in one place for the same amount of error in other places and eventually i lost interest in pushing this further (i started with random changes + threshold accepting. quick results, but also very quickly i reached a dead-end here).
Still, i had some ideas, but neither the time nor the brains to give them a try. I bet you came across these ideas already yourself, but i got the feel i need to dump them here anyway:
1) i always used sum of absolute squared error (compared to an "ideal" dfli-picture) for measuring fidelity. i believe there is a lot of potential in other measurements. Dunno, something more perceptive or some model that factors things like pal-color-bleeding in...
2) something probably not that difficult would be to add weighting to the errors to help the optimizer take the right decisions. that could be a user-provided region-of-interest or something based on image-features (e.g. sharp corners)
|
|
Posted By
bubis
on 2018-10-31
08:35:05
| Re: DFLIConv2
Hi Ingo,
I haven't tried to make it adaptive yet, but that is a good idea. Maybe even a pre-optimization phase would make a difference, some analisis to decide where you need more luma or more chroma badlines.
First, I want to make sure that I have an optimizer that produces very close results to DFLI mode in generic mode with DFLI badline settings. Those should be equivalent, but normal DFLI consistently produced less conversion errors until now. (I explaind the reasons for this above.)
"Until now", because last night I added a multi-variable optimization algorithm to the mix (it perturbs one to three variables at once if the overall number of combinations is below a limit) and now that sometimes produces less error for the generic case. It tries all chroma-chroma, chroma-luma, luma-luma pairs and all chroma-luma-luma and chroma-chroma-luma triples even when those are (naturally) components of different colors. Most of the gain is coming from triple var optimizations.
Still, I couldn't come up with an image yet that produces much better results with some unconventional badline settings. Maybe adaptation is the key. It is hard to believe that DFLI is always the optimal badline sequence.
|
|
Posted By
Degauss
on 2018-10-30
18:29:24
| Re: DFLIConv2
Thanks for doing this! Its especially nice to have different configs under one hood. Great work!
I once played around with adaptive changes between c and l lines to reduce error but my results (didn't put much effort in it admittedly) didn't give any bigger gains. You ?
|
|
Posted By
bubis
on 2018-10-30
15:54:53
| Re: DFLIConv2
All fli routines what I (will) include in the converter set multipe ted registers in every rasterline, so modifing them to create split screen will be easy and again, it supports custom size conversion by default.
|
|
Posted By
MMS
on 2018-10-30
14:41:59
| Re: DFLIConv2
These things are awesome. Very nice that there is a nice followup of a previous, 15 years old tool, with new developments.
BTW one question: is it possible to make split screen routine, with (x)FLI on the top, and 5-7 lines of character screen oat the bottom? (and certainly a supporting format, as an output). I do not know, how much CPU power remains, how responsive the system remains on those character areas, and if the mode switches not kill the timing of the display.
Recently the (graphical) adventures got some interest. We all know, that Plus/4 is very capable to show fantastic pictures in slideshows and demos, but an almost Amiga quality graphical adventure would be something really fantastic, and may raise some interest towards the platform. (we had a lot of dispute, that in multicolor mode the Plus/4 has even a limitation in the 3rd atttribute color, that's why most of the converted C64 pictures had some strange color palette. But it would be different for FLI and self converetd pictures )
A Kernal like loader routine + a displayer (plus the proper format output from the converter) would be enough to support the creators.
The bigger platforms (ZX Spectrum, C64, Amiga even PC) are using kindg of adventure maker programs, like Quill, PAWS, we do not have. But in case the above routines could have been supported BASIC, it would be enough good environment for a quick development. (I do not think that anyone would start to create an adventure in ML for Plus/4, too big task).
|
|
Posted By
bubis
on 2018-10-30
13:07:48
| Re: DFLIConv2
It seems to me that you get very similar results for the average picture. It is impossible to tell what was your fli settings by looking at the results for most of the cases. I couldn't yet find one picture that stands out in one or the other new fli modes.
The reason why I am saying that my converter is %100 not up the task yet is this: In theory 'clclclcl' is what we call DFLI, but the conversion error for DFLI is always smaller than the conversion error for the generic mode with 'clclclcl' settings. So, I can't trust the converter yet to create really good results for the generic mode, so it is too early to compare.
Maybe when I improved the optimization algo I will find proof that some pictures are better to convert to 'clllclll' than anything else (at least with my converter), but now this is still experimental...
The reason for not getting the same results as DFLI is very simple. DFLI handles every color as one variable, the generic case has chroma and luma components. The algo that tries every value and keeps the best is one dimensional, so it will not try all the combinations of chroma and luma that forms a single color to find the best combo. It will rather try every luma, keep the best and try every chroma and keep the best. It is 121 vs 16+8 cases and the two step method can't compare all the chrome+luma combinations (yet). So, in a sense the DLFI case is more brute-force-ish than the generic. I will work on that...
|
|
Posted By
Mad
on 2018-10-30
10:03:15
| Re: DFLIConv2
WOW! That is some extremely awesome news! Now with some flexible FLI! Interesting idea, keen on the (visible) results by that routine.
|
|
Posted By
bubis
on 2018-10-31
08:11:10
| DFLIConv2
Hi,
I think it's better to start a new topic for DFLIConv2. I don't expect big traffic, but it's still better.
So, let me copy here my last comment from the sic-p4 image converter topic (what is about Sandor's great converter btw):
Do you remember what FLI stands for? Flexible Line Interpretation.
So, in the next release FLI will be really-really flexible! You can decide for every rasterline in a character row what kind of DMA (badline) you want.
The normal badline sequence is 'c------l', because (l)uma is loaded in the previous character row's last rasterline and (c)hroma is loaded in the top most rasterline of the character row. That means that a (c)hroma badline has an immediate effect but a (l)uma badline has a delayed effect.
Some possible examples for DMA config:
- 'clllllll' will mean you want one chroma update and 7 luma updates per char row.
- 'clllclll' will have one chroma and three luma updates per 4 rasterlines.
- 'c--l---l' will produce a normal badline sequence with one extra luma update in the middle of the character (semi-qfli ?).
- You can even have 'llllllll' or 'cccccccc' where you have either luma or chroma updated in every rasterline!!! In that case you will have fixed luma or chroma values for the whole column on the screen because we don't have time to update them (those are pre-loaded wih extra badlines before TED starts rendering the window).
I think my converter is not 100% up to the task for these new modes yet, but the results are already pretty good so, I will release this as an experimental mode later this week.
|
|
| |
Copyright © Plus/4 World Team, 2001-2024. Support Plus/4 World on Patreon |
