Posted By
Luca
on 2008-01-14
16:30:54
 |  plus4emu FLI converter
[This thread follows up from this post. The last IstvanV's revision of his own converter is this one.]
I see that Istvan Varga is making the very first Plus/4 dedicated image converter, he looks addicted to the matter, he's coding it very versatile and working, he's damn fast in doing it.
I repeat: the first ever. We just had examples of picture drawing programs, we never got an all-formats converter, and we'd never seen a FLI picrure quality like this.
Yes, I am the first one to pray for a global stuff which can do everything, and I see Istvan's stuff as a good starting point to achieve, in a short time at this speed, exactly that tenaciously craved target.
Gaia, beg your pardon, but in few rows you asserted: the plus/4 graphicians need different stuff; this converter would aim to be like honey for c64 ppl that only because of this would be interested; because this is "another converter" on Plus/4 (eh!?  ) it wouldn't be enough to let c64 ppl income with new releases; native Plus/4 graphicians are a crazy variable and can't be predicted in their decisions; the same ppl (graphicians) that would be interested in different stuff at point 1 to be honest hare a bunch of few desperate guys 
Well, of course I exxagerated in order to laugh, but i must admit I'd never thought at this program as an appealing fruit for the c64 masses, it's a pretty interesting point of view anyway...
Also, my wish (and hope) would be to see the sceners shake their face and restart enjoying the little black box, before awaiting interested ppl from other scenes: nukem has recalled to us we lack of simple and polite releases; Degauss has recalled to us you can spend few hours to show your skill in optimizing a 256bytes demo and collect interest (see Pouet) about this, also because his achievement enter an important field of scenes'interaction
And finally: if you have a secret Plus/4 conversion stuff hidden somewhere, dig it out, 'coz I can't recall it in my mind! .
Happy to discuss this topic with all of us, finally a bit of life! Much happy to discuss this at pH=7! 
|
|
Posted By
Dr. Death
on 2008-01-14
17:01:45
| Re: plus4emu FLI converter
In between all this, i'd like to drop an idea:
I'm no graphician so i don't really know what kind of tools a real graphician would prefer, but i know the ruleset for a +4-FLI-picture is quite hard to master: picking the right BG/FG-Color values, probably X-Shifts... terrible. So my idea always was to have some sort of "converter-assisted pixelling": You should be able to pixel freely with all the 121 colors and let the converter help you finding (and solving) the areas where you were putting too much colors in. If done right, that could be a simple "addon" upon a straight converter-tool.
To be honest, this is what i always wanted to do with my converter, but ATM i like Istvans better.
p.s.: An example where "converter-assisted pixelling" could be a benefit is this: As a graphician, you would normally choose the most used color in a line to be assigend to the FF15-register. A converter probably would decide differently: It would use the videomatrix for the most used color so FF15 is still free to resolve an important color-bug somewhere else in the line (at least, thats what my converter does to reach a higher color-density)
|
|
Posted By
Luca
on 2008-01-14
17:03:27
| Re: plus4emu FLI converter
Hey Ingo is claiming a smart-converter!
|
|
Posted By
Litwr
on 2008-01-19
00:45:45
| Re: plus4emu FLI converter
Excuse me but how to run this p4fliconv.7z?
|
|
Posted By
IstvanV
on 2008-01-19
05:11:29
| Re: plus4emu FLI converter
The archive is in 7-Zip format, which you can unpack with tools that can be downloaded from here: http://www.7-zip.org/download.html. On Windows, just extract it to a plus4emu installation directory, so that p4filconv.exe is in the same directory as plus4emu.exe, and src/SConstruct is overwritten. On other platforms, it can be built from the included source code; first, unpack the latest plus4emu source package, and extract p4fliconv.7z to the same directory, overwriting SConstruct, for example, assuming that you have plus4emu-1.2.5.tar.gz and p4fliconv.7z in the current directory:
tar -xpzvf plus4emu-1.2.5.tar.gz
mv plus4emu-1.2.5 src
7za x p4fliconv.7z (type 'Y' to overwrite SConstruct)
rm p4fliconv.exe
cd src
(edit SConstruct, and disable win32CrossCompile and maybe buildRelease as well;
also edit src/gldisp.hpp, and replace the 'private:' at line 33 with 'protected:')
scons p4fliconv
If building from source code does not work for some reason, you can also run the Win32 version with WINE. I plan to release a new minor update to plus4emu in a week or so, which will include the image converter utility.
|
|
Posted By
Litwr
on 2008-01-19
05:22:16
| Re: plus4emu FLI converter
Thanks. However why to use so exotic format? Is it much better than tar.bz2? BTW the mentioned site with 7-zip is offline now. 
|
|
Posted By
IstvanV
on 2008-01-19
05:37:56
| Re: plus4emu FLI converter
I have very limited space on the sharemation site, since there is a quota of only 5 MB. When compressing large binary files, LZMA compression can be about 20% smaller than bzip2, which can be useful when I often have to delete old files to free space for the new ones. However, if no one needs the old converter comparison package (p4imageconv.rar) which is 1.7 MB, I can delete it, and replace the other files with plain old .zip packages. So, can I delete p4imageconv.rar ?
Of course, this issue will be irrelevant when the next plus4emu version is released on SourceForge.
I just tried downloading the p7zip sources, and there seemed to be no problems.
|
|
Posted By
Litwr
on 2008-01-19
05:41:06
| Re: plus4emu FLI converter
Yes, yes, I've also found many links in net - all is ok! thanks again.
|
|
Posted By
IstvanV
on 2008-01-27
18:59:38
| Re: plus4emu FLI converter
Are there any bugs or other issues that need to be fixed before it can be released ?
|
|
Posted By
Luca
on 2008-01-27
19:03:46
| Re: plus4emu FLI converter
Mmmmmno, I played a lot with it, you only have to balance the image, the sensibility, contrast etc... It's a joyful toy anyway
|
|
Posted By
IstvanV
on 2008-01-28
07:30:40
| Re: plus4emu FLI converter
It could also be possible to add more video modes, for example the earlier greyscale only conversion, although the only advantage it has is being able to set attributes independently for 8x1 blocks, rather than 8x2, which is not much compared to the disadvantage of losing colors.
Another idea, originally from TLC, is using NTSC mode to increase the horizontal resolution, as well as to make the visible area wider (41.6 characters), but I do not think this overclocking trick is very useful in practice, particularly since it only allows MC resolution with 3-4 colors for the whole screen. An example of two images in one PRG file, and conversions of the same images in the high resolution color mode for comparison can be found here:
http://www.sharemation.com/IstvanV/ntsc/ntsc.prg
http://www.sharemation.com/IstvanV/ntsc/image1.prg
http://www.sharemation.com/IstvanV/ntsc/image2.prg
What would be really useful is adding full multicolor mode conversion with "horizontal interlace", although it is probably the most difficult one to implement.
|
|
Posted By
Luca
on 2008-01-28
07:41:08
| Re: plus4emu FLI converter
IstvanV, I really would like to see multiformat conversion in one tool, starting for the most simple ones: plain bitmap MC and 4 fixed colours characterbank based MC with char compression in variable sizes (yes, exactly, the logos stuff).
With your code's features, both would have great colour clashes reduction routines...
PS: brrrr, your example pics scare me everytime :)
|
|
|
Posted By
IstvanV
on 2008-02-01
08:38:48
| Re: plus4emu FLI converter
This updated version (http://www.sharemation.com/IstvanV/flitest/mcfli_test2.prg looks slightly better, although it is still not quite perfect. Any opinions ? Should I include this mode, or is it not useful enough (note that the MC conversion is also rather slow at the moment) ?
|
|
|
Posted By
IstvanV
on 2008-02-21
10:15:35
| Re: plus4emu FLI converter
I have now changed the multicolor FLI converter to take advantage of the increased resolution of the two background colors, although it only seems to result in a very minor quality improvement, and it does slow down the conversion somewhat. In fact, for most images, just changing the old code to optimize the palette more results in better quality/speed ratio. The algorithm could probably be improved, though.
|
|
Posted By
Dr. Death
on 2008-02-21
13:06:11
| Re: plus4emu FLI converter
Hi Istvan!
Just a suggestion: Try some other test-images. My experience was that sooner or later you find images with "troublesome" conditions (high contrast areas etc).
|
|
Posted By
IstvanV
on 2008-02-22
10:03:43
| Re: plus4emu FLI converter
Hi ! It does of course make more difference with test images that really require the high color resolution (e.g. a screenshot of the 'flitest.prg' example), but for typical images there are usually only a few lines where the background colors change within a pair of lines. However, this is probably in large part because the current algorithm basically does the old-style conversion first, and then tries to reduce the error in a second pass by changing the background colors separately for each line. I have experimented with various ways of optimizing the colors in a single loop, but so far this always resulted in either too much slowdown, or slightly worse - rather than better - quality, or both.
|
|
Posted By
IstvanV
on 2008-02-23
07:54:32
| Re: plus4emu FLI converter
I have just noticed that TLC FLI Collection, which was released in 1998, uses interlacing to increase the vertical resolution, although it is apparently not mentioned in the description. However, there seems to be a minor problem: the fields are swapped on plus4emu, YAPE 0.79, and my real Plus/4 and TV card as well. Is this hardware specific (i.e. there may be TVs or monitors on which the effect works correctly), or is it a bug in the demo ?
|
|
Posted By
Gaia
on 2008-02-23
10:28:20
| Re: plus4emu FLI converter
It's an unfinished routine, not even a demo, so probably a bug, but only TLC could tell...
|
|
Posted By
IstvanV
on 2008-02-25
10:23:13
| Re: plus4emu FLI converter
Dr. Death: for now, I have simply made the multicolor conversion quality adjustable in the configuration, so the user can choose from lower quality, but fast conversion, to higher quality but very long processing time (which is normally only to be used for the final version of the image). With the new display routine, more video modes (non-interlaced hires and multicolor FLI, and simple hires mode without FLI), and C64 image format reading support, a new "beta" version will hopefully be available soon.
|
|
Posted By
IstvanV
on 2008-02-27
14:07:09
| Re: plus4emu FLI converter
It can be downloaded now from here: http://www.sharemation.com/IstvanV/p4fliconv_sse.7z
There is also another download (p4fliconv.7z) for older machines; it is only useful if you have a CPU that is not at least a Pentium 4 and does not support SSE/SSE2 instructions.
|
|
Posted By
Luca
on 2008-02-28
17:54:29
| Re: plus4emu FLI converter
Uffff, doesn't work to me
|
|
Posted By
IstvanV
on 2008-02-28
19:24:57
| Re: plus4emu FLI converter
I have uploaded the packages again (with some minor bugs fixed), so the downloads should work now.
|
|
Posted By
Luca
on 2008-02-28
20:17:11
| Re: plus4emu FLI converter
The sample is somewhat incredible, but the .exe doesn't work to me, giving an MS error message
|
|
Posted By
IstvanV
on 2008-02-29
07:14:25
| Re: plus4emu FLI converter
Does the version that was included with plus4emu 1.2.5.2 also crash on the same machine ? If not, then make sure that the file mingwm10.dll is also extracted to the same directory as p4fliconv_gui.exe; the simplest way to get a working installation is to extract the package to a plus4emu installation directory, overwriting any old files (this also allows running the program from the start menu). You can also try the slower non-SSE build in case the problem is caused by the use of special CPU instructions (the previous versions were all compiled with the settings of the "compatibility" package).
Some more questions: does the crash occur immediately on start-up, or the program starts, but crashes later, for example when opening a file ? Does command line conversion using the console version (p4fliconv.exe) work ? What is the actual error message ?
|
|
Posted By
Luca
on 2008-02-29
07:56:58
| Re: plus4emu FLI converter
I've just tried all this before moaning: .dll, non-sse, overwriting etc... Yes, all the previous versions ran on that machine, and the error message is the classic MS error window, and it occurs immediately at doubleclick.
|
|
Posted By
IstvanV
on 2008-02-29
09:25:40
| Re: plus4emu FLI converter
This is really strange. I do not know what change could have introduced this problem. Do the old 1.2.5.2 exe files run now, if you reinstall those (without changing anything else) ? Did you try the command line interface (for example, just running 'p4fliconv.exe --help' to see if that works, or some simple conversion like 'p4fliconv.exe foo.jpg foo.prg') ?
It would also be interesting to see where the crash happens in the code; although the files do not have debug information, if you could post just a stack trace of code addresses (included with the error message or error log generated by Windows), that would be useful.
By the way, what version of Windows are you using ? Does anyone else also have this problem (all the .exe files run fine on my machine) ?
|
|
Posted By
Luca
on 2008-02-29
09:57:28
| Re: plus4emu FLI converter
I use a simple traditional XP with SP2, and once reinstalled the old version, everything works ok...
|
|
Posted By
IstvanV
on 2008-02-29
10:11:14
| Re: plus4emu FLI converter
Well, then I do not have much ideas left. Although someone mentioned having problems on a dual monitor machine earlier, but as far as I know, that should have been solved by upgrading the FLTK library. In any case, if you can send the complete error log generated by Windows (with the stack trace etc.), that could help finding out where the program actually crashes.
|
|
Posted By
IstvanV
on 2008-02-29
14:17:08
| Re: plus4emu FLI converter
Any news ? Since I cannot reproduce the problem myself, I cannot fix it without more information
|
|
Posted By
Luca
on 2008-02-29
14:46:17
| Re: plus4emu FLI converter
Waitwaitwait, the non-SSe works fine for me
|
|
Posted By
Exin
on 2008-02-29
15:01:39
| Re: plus4emu FLI converter
Hmmmm...this version of the FLI converter with gui gives me rather small images....The image size part in the gui version seems bugged and fixed to 128....
|
|
Posted By
IstvanV
on 2008-02-29
16:08:46
| Re: plus4emu FLI converter
Luca: thanks for the information, finally some good news I assume this means that it is not necessary to investigate this problem further, and I should just continue to build both SSE and non-SSE versions (the latter do run about 1.5 times slower on my machine for multicolor conversions, so the difference is not insignificant) ?
Exin: this problem sounds even more weird. For me, the GUI controls seem to work fine under WINE, and native Windows as well. Is 'Vertical size' the only one that is not behaving as expected ? Can you change it by clicking on the number with the mouse, and then dragging to the left or right with the mouse button held down, or by typing in a value directly, or are both methods broken ? Is it possible to set the value on the command line (with the -size N option) when starting the GUI, or does that get changed to 128 too ?
|
|
Posted By
Luca
on 2008-02-29
16:30:52
| Re: plus4emu FLI converter
Just to say: to me it's work fine, and the new "x-opening" for the .prg viewer is cool Now I'm playing with Koala conversion
|
|
Posted By
IstvanV
on 2008-03-01
11:23:55
| Re: plus4emu FLI converter
On a somewhat related note, would it be useful to have special support for reading images that use the Plus/4 palette, and converting those to the multicolor formats with as close to pixel exact quality as possible ? While it can already be done, it requires very specific conversion settings, image size, and input palette to avoid additional quality reduction due to interpolation and color mapping (particularly in the case of the very dark and bright colors which are clipped in the RGB colorspace).
The image opening/closing effect in the viewer can actually be enabled/disabled with a flag in the image data (perhaps a description of the data format would be useful ?), although there is no configuration option yet in the converter UI to change that. The effect can also be easily changed in the viewer source.
|
|
Posted By
IstvanV
on 2008-03-02
09:48:37
| Re: plus4emu FLI converter
There are updated downloads now with some minor bug fixes.
|
|
Posted By
Luca
on 2008-03-02
19:36:34
| Re: plus4emu FLI converter
So, let's perform some testing with the very last version, in particular about palettes.
This is Fantasy Hair drawn in Koala Paint format by Almighty God on C64 for the Oxyron Party 2008. Please look at the colour clashes because of the c64's 3 colors per char feature (especially in the mostright low corner, around the sign).
|
|
Posted By
IstvanV
on 2008-03-03
08:05:31
| Re: plus4emu FLI converter
There is also some visible quality reduction in the dithering of the red circle. However, if the brighter pixels at the lower right corner are more of a problem, then it may make a difference to change the scaling of the U and V error with respect to the Y error (that is, how important is the color information compared to the luminance). This is fixed to 0.5 in the current version, but changing the value to 0.25 results in this image (using plain multicolor mode, of course, FLI would look better):
http://www.sharemation.com/IstvanV/fantasy_hair_mc.prg
Now the bright pixels are mostly gone, at the expense of more merging of colors with identical luminance. Would it be a useful feature to make the color error scale adjustable in the advanced settings ?
|
|
|
Posted By
Luca
on 2008-03-03
09:50:53
| Re: plus4emu FLI converter
Yes, a dedicated setting for this kind of operation would be quite friendly, 'cause it looks to be a common point for any kind of converting from C64 MC (looking forward to their features which will appear). Of course, the real fixing will be performed via pixel editing, but that would also be a very valid help.
Moreover, looking for a comfortable Multi Botticelli editing, it would be also cool a RAM color uniformity: take a charsized area with its own Col1 and Col2, located in (x,y); if a color(e.g. Col1) in the charsized areas close to it is the same of Col1 or Col2 in (x,y), then (x,y) will swap that color to Col1 too. It will be very useful even in the HiRes case!
|
|
Posted By
Dr. Death
on 2008-03-03
18:05:26
| Re: plus4emu FLI converter
argh, i missed all recent developments... gotta catch up soon.
|
|
Posted By
IstvanV
on 2008-03-04
17:33:34
| Re: plus4emu FLI converter
Luca: the multicolor error calculation tuning parameter is now implemented, and the downloadable package is updated (note that there is a single http://www.sharemation.com/IstvanV/p4fliconv.7z file now, and it contains both the compatibility and fast SSE build of the program).
I will also try implementing the "editor friendly" color RAM use later; I assume it is only needed for the non-FLI modes ?
|
|
Posted By
Luca
on 2008-03-04
22:06:43
| Re: plus4emu FLI converter
Yes, non-FLI only, it's a feature that will be very useful for further editinf of C64 converted MCM and HR pictures.
Looking forward to a charset stuff too...
|
|
Posted By
IstvanV
on 2008-03-05
11:05:38
| Re: plus4emu FLI converter
Well, I recall you have suggested three logo editor formats (Logo Paint, Logo Editor V2.0, and Logomaker +40), so which one should be implemented first ? Is a greyscale-only conversion sufficient, or should the colors of the original image also be converted (which may possibly not look very good with a 128x64 4 color format) ?
There are a few more changes I planned, but do not know if any of these are actually needed by anyone:
- GIF (and generally indexed) format reading
- pixel exact reading of images using the Plus/4 palette, similarly to the way the C64 formats are handled
- more dithering modes (e.g. ordered with simple non-randomized patterns)
|
|
Posted By
Luca
on 2008-03-05
11:35:12
| Re: plus4emu FLI converter
Logo Editor V2.0 as first. Greyscale-only is enough, because the converter simply should "reduce and dither" an usual bmp/png/jpg, or a c64 one...or a Multi Botticelli one too, why not?
|
|
|
Posted By
IstvanV
on 2008-03-06
06:16:56
| Re: plus4emu FLI converter
Although I did not mention it yet, but the download was updated yesterday, so you can already test if the color remapping is an improvement in practice. A bug has also been fixed.
|
|
Posted By
IstvanV
on 2008-03-10
11:17:12
| Re: plus4emu FLI converter
Here is a simple multicolor Logo Editor V2.0 conversion: http://www.sharemation.com/IstvanV/blahlogo.prg
This only displays black and shades of grey, but it is possible to change it to any gradient by editing the palette at $1100-$1103. To create a Logo Editor compatible file from this, just save the memory area $6000-$6800 to disk in the TEDMON. The converter will also allow saving Logo Editor files directly when the "raw" mode is enabled, but these files do not include palette information (however, the four color palette is printed on the GUI after conversion).
Should I upload a new version that includes this format ?
|
|
Posted By
Luca
on 2008-03-10
12:16:30
| Re: plus4emu FLI converter
Wonderful! Yes, upload it absolutely, wanna play a bit with that stuff!
Ah, I did not see you've uploaded the converter some days ago..
|
|
Posted By
IstvanV
on 2008-03-10
19:06:56
| Re: plus4emu FLI converter
The updated version is now uploaded.
|
|
Posted By
Luca
on 2008-03-11
06:51:08
| Re: plus4emu FLI converter
I had a little time to try the new features the past night, and I have to say it was GREAT FUN! Especially playing with dithering, X/Y position and, most of all, X/Yscale!
|
|
Posted By
Dr. Death
on 2008-03-11
13:41:19
| Re: plus4emu FLI converter
Have to second Luca. Besides the fact that the tool is very useful, it reminds me a bit of Llamasofts Psychedelia
@Istvan: I don't want to be bold about feature-requests but: How about an export-option that results in a .bin-file and a short driver (would make it easier for a demo-coder to use your tool)
|
|
Posted By
IstvanV
on 2008-03-11
17:09:07
| Re: plus4emu FLI converter
I am not sure if this is exactly what you meant by a .bin file, but checking the option 'Write the raw FLI data only' allows for saving just the actual video data without any viewer code. The assembler source of the FLI viewer (p4flidisp.s) is included with the package, and can be compiled with ca65; the code takes up the first 2K of the basic memory (not including the unrolled FLI display code which is created by the viewer at run-time), so it is not particularly short, but for use in an actual demo, many unneeded parts can probably be removed.
The non-FLI modes use the formats of Botticelli, Multi Botticelli, and Logo Editor V2.0, and the files are loaded to $7800-$9F40 (graphics) or $6000-$6800 (character sets).
The FLI data format is loaded to $17FE, with the end address ranging from $6000 to $E500, depending on the details of the video mode (interlacing, overscan, etc.). A short documentation is available here: http://www.sharemation.com/IstvanV/fli_mem.txt. Hopefully there are not too many typing errors
Files can also be saved in compressed format, if the 'PRG compression' is set to a greater than zero value, although this format is somewhat complex, and slow to decompress. A "raw compressed" file includes only the compressed video data (loaded to the same start address as without compression), with no decompressor or viewer code at all. The non-raw compressed files (like the sample programs included with the downloadable package) are self extracting and include the viewer.
Of course, more output format options can be added, if needed.
|
|
Posted By
Dr. Death
on 2008-03-12
08:28:33
| Re: plus4emu FLI converter
Oh, that was my fault. I didn't notice the "Write the raw FLI data only" option. Yes, thats everything a demo-coder needs.
Which compressor did you use?
|
|
Posted By
IstvanV
on 2008-03-12
09:54:12
| Re: plus4emu FLI converter
The compressor is my own code, it is somewhat similar to the zip/gzip format, but the compression ratio is better. However, it has the disadvantage of a large and slow decompressor, so you would probably want to use an external compressor instead in most cases; the viewer does not include any code for decompressing, it just calls a subroutine through the vector at $17F4 if the data is flagged as being compressed.
|
|
Posted By
Exin
on 2008-03-16
19:28:29
| Re: plus4emu FLI converter
Is it time to demand format features?
additional File formats:
Pixelshop (Hires and multicolor)
FliEdit (Multicolor fli)
|
|
Posted By
IstvanV
on 2008-03-17
08:42:43
| Re: plus4emu FLI converter
I have thought of adding PixelShop format support earlier, or writing a separate utility for converting between various Plus/4 FLI formats, although the P4S format does not seem to allow for including all the information that is in the converter output (for example, X shifts cannot be saved, so that should be set to zero in the conversion options).
Perhaps it would also make sense to have an utility to convert from P4S to the p4fliconv format, so that the files edited with PixelShop can be displayed with my FLI viewer ?
I am not sure what 'FliEdit' is, since I could not find a program with this name. Is it FED ? If yes, then it should be simple, but the format is limited to 160x200 multicolor FLI with X shift = 0 (that is, it is not possible to correctly save this type of file if any other converter settings are used).
|
|
Posted By
IstvanV
on 2008-03-17
09:02:39
| Re: plus4emu FLI converter
By the way, this utility does not seem to be listed on the "Tools" page.
|
|
Posted By
Exin
on 2008-03-17
12:46:27
| Re: plus4emu FLI converter
Hi there
Xshift is almost useless for real drawings, so not needed.
And Pixelshop doesn't have FLI support. Maybe you could add a seperate chart for the output file format. Including an orption whether to include the X shift value or not.
|
|
Posted By
IstvanV
on 2008-03-17
14:25:12
| Re: plus4emu FLI converter
Hi ! From the documentation and the user interface I thought that PixelShop supports FLI. So, I can assume that it is actually unimplemented or buggy ? If that is the case, is PixelShop limited in practice to plain 320x200 hires or 160x200 multicolor formats with no FLI, overscan, or interlace ?
Any information on what "FliEdit" is (I could not find a program with this exact name, and there are multiple editor utilities for Plus/4 multicolor FLI) ?
|
|
Posted By
IstvanV
on 2008-03-18
11:50:43
| Re: plus4emu FLI converter
I did some tests now, and it seems that PixelShop can read FLI images, and also images with a height other than 200. While I did not check how reliably it works in those cases, it will probably be enough to reject interlaced FLI and X shift only, anything else can be saved in P4S format.
|
|
Posted By
Luca
on 2008-03-18
14:27:12
| Re: plus4emu FLI converter
I played with the converter and some old images in hours today, having lot of fun with a bunch of friends, playing with the features, converting and passing on the Plus/4 in order to see the final result . I simply love this powerful toy, we should find a friendly name for it.
|
|
Posted By
IstvanV
on 2008-03-19
19:04:38
| Re: plus4emu FLI converter
Exin: I have mostly implemented the new output formats now, and an updated version that can save P4S and P4I (FED) files will be available soon. I will also add a separate utility that converts from P4S to all the supported output formats.
|
|
Posted By
IstvanV
on 2008-03-19
19:09:32
| Re: plus4emu FLI converter
Luca: well, the current name of 'p4fliconv' is probably not very imaginative, but finding good names is not something I am particularly good at However, if there is a suggestion for a better replacement, it can be renamed.
|
|
Posted By
degausssss
on 2008-03-19
20:43:26
| Re: plus4emu FLI converter
hi istvan!
a first suggestion: fli-circus. handling all the different aspects of the image conversion must be comparable to drilling fleas
after a long time of just reading the thread i played for quite a while with this tool and i have to say i like it very much. the thing i like most is the preview-option (PAL-preview! how cool is that!), the real-interlace-mode and the support for all relevant formats.
i don't want to bomb you with feature-requests, but i like to make some suggestions for further improvements. there are only few things i would love to see and these are just ideas, so please don't kill me:
1. your "preview" mode already shows the final result. from my experience and due to the highly saturated nature of the +4-palette i always felt the need to see a preview after all the preprocessing-steps (like gamma-correction etc..). in my converter (see below) i solved this with a preview that shows an "idealised" picture, color-reduced and dithered to the +4-palette.
2. different x-shifts per line (i know, i'm quite fixated on this )
3. interlaced modes where both fields share the same videomatrix. (this should be quite useful for all cases/demos where you don't have too much ram left)
4. a bit more exotic: special support for monochromatic modes. the display-kernel-routine only refetches the luminance-attributes.
5. even more exotic: an adaptive approach that decides if the display-kernel-routine refetches the color or luminance portion to reduce error.
-------------
my converter:
you can download a WOP-version of my converter here:
http://www.jache.de/download/flinteractive_preview.zip
the application is full of rough and dirty code, tends to crash and has lots of inferior approaches (e.g.: i use RGB instead of YUV all the time). so don't look too close
look at the readme-file to see how you can play around with the scrollbars and keys 1-5 to have a quick (pre-)preview. maybe this is something you would like to have in your app aswell. i still think its handy to compare "optimal" versus "possible". that would be even more interesting in your app, since you are able to show a PAL-preview.
regards
degauss
|
|
Posted By
Chronos
on 2008-03-20
03:17:32
| Re: plus4emu FLI converter
you guys are real gods! the converter getting better and better day by day!
|
|
Posted By
IstvanV
on 2008-03-20
18:43:58
| Re: plus4emu FLI converter
Hi Degauss !
Changing the display of the original image to be affected by the color correction settings would be easy, although it would need to be updated (which is slow) whenever those settings are modified. A color reduced and dithered "ideal" image is somewhat more tricky, considering that all the various video modes need to be supported, while the PAL preview is actually Plus/4 emulation, so it just loads and runs the generated program. But it would be a useful feature for the multicolor modes, which do work by creating the "ideal" dithered image first, and then converting it, so I will try implementing it eventually.
The X shift can already be set independently by the converter for every line when it is set to "optimized" in the options (although in the specific case of interlaced hires FLI, it is only allowed to change by at most one pixel per line; in the other modes, all possible values are searched by brute force, for example the multicolor FLI modes try 4x4=16 combinations for each pair of lines). Or did you mean being able to set it manually for each line ?
Adding bitmap-only interlace modes is indeed on the list of features to be implemented. If I recall correctly, you did already mention this some time ago, but I did not get to actually implement it yet.
I do already have an older utility (interlace6.cpp) that converts to greyscale-only hires FLI where the luminance attributes are updated for every line, rather than pairs of lines, and also posted some example programs earlier. It is very simple code, though, so many improvements could be made.
I tried your converter, the quality is actually very good.
|
|
Posted By
Dr. Death
on 2008-03-21
09:18:03
| Re: plus4emu FLI converter
Hi Istvan!
Ah, i guessed you're running the prg in your emu. So i guess there's no "elegant" way of showing a plain pixelarray through a PAL-filter. I found out that instead of having a preview-mode, it's also ok to load/save the "give good results"-settings.
If i would have looked a bit more closely on your documents, i would have noticed that the x-shifts are independent per line, sorry . a thing i was wondering about: is there a reason for the constraint in hires-fli (x-shift can change one pixel at most)? i presume the resulting image would have too much jitter-effects otherwise, right?
Regards
Degauss
|
|
Posted By
IstvanV
on 2008-03-21
20:02:33
| Re: plus4emu FLI converter
Hi ! Yes, the limitation of X shift change in interlaced hires FLI mode is mostly an attempt to make the output more stable, but it also reduces the number of combinations to be tested if four lines are optimized at once, there are only 81 iterations instead of 4096 then.
By the way, while the file format may suggest that background colors can also be set independently for each line, it is actually only the case if there are at most 200 lines per field. Otherwise, the FF15 color can only be changed in odd lines if the FF07 value does not change in the same line.
|
|
Posted By
IstvanV
on 2008-03-21
20:10:21
| Re: plus4emu FLI converter
The beta package (http://www.sharemation.com/IstvanV/p4fliconv.7z) is now updated. As requested by Exin, PixelShop and FED format files can be written, and there is also a new utility (p4sconv) that can convert P4S files to any of the supported output formats. Other than that, there are various minor changes, more dithering modes, and a preliminary interlaced multicolor FLI mode where only the bitmaps are interlaced. It does not interlace the background colors and X shift either, though, so the quality is not optimal; these limitations can hopefully be removed later.
|
|
Posted By
IstvanV
on 2008-03-23
20:13:13
| Re: plus4emu FLI converter
Another minor update: the bitmap-only interlace is now also implemented in high resolution mode, and in multicolor mode it can interlace the background colors for a small improvement in quality. The X shift is still not interlaced in either of these new modes, though.
|
|
Posted By
IstvanV
on 2008-03-28
13:05:07
| Re: plus4emu FLI converter
The p4fliconv.7z file has been updated again: colors are now dithered more accurately in multicolor modes if ordered dithering is used; previously, the hue was inaccurate at low saturation. Assembler sources for decompressing the "raw compressed" format are also included now; the code might need to be cleaned up somewhat, but it seems to work. By the way, one change in the previous version that I did not mention is different error calculation in the multicolor modes - it may need more experimenting, but it does look better now than with the older releases.
|
|
Posted By
Exin
on 2008-04-03
16:42:02
| Re: plus4emu FLI converter
Hi Istvan!
With SSE you robably mean SSE2? It doesn't seem to work on my Pentium 3 Notebook.
Exin
|
|
Posted By
IstvanV
on 2008-04-03
18:32:20
| Re: plus4emu FLI converter
Yes, the SSE binaries (p4fliconv_sse.exe and p4fliconv_gui_sse.exe) were compiled with the Pentium 4 instruction set, and use both SSE and SSE2. All other .exe files use only Pentium 2 instructions, and should run on most machines, although multicolor FLI conversion (which takes the longest time, at high quality and using optimal X shifts) is about 1.5 times slower on my machine when using the non-SSE executables.
|
|
Posted By
IstvanV
on 2008-04-04
19:25:40
| Re: plus4emu FLI converter
There is a new p4fliconv.7z package available for download now. It adds support for reading .gif and .xpm files, although transparency is currently ignored (unlike in the case of RGBA PNG files, where it blends with the border color), and named colors like "Black" instead of "#000000" in .xpm files are not allowed. XPM format images that use a palette that has at least 128 colors and is sufficiently similar to the Plus/4 palette are handled in a special way, similarly to .koa and .ocp: the color indexes are mapped directly to Plus/4 colors, the image size is scaled only by integer ratios and without interpolation, and color correction is disabled.
Other changes include the addition of yet another dithering mode (mostly for interlaced multicolor modes, where dithering is often problematic), and some optimizations in the decompress.s file, which, if enabled, improve the speed by a few percents at the expense of increasing the code size by 6 bytes.
|
|
Posted By
Luca
on 2008-04-05
02:45:48
| Re: plus4emu FLI converter
This damn toy is becoming more funny release after release.
Playing with it, you feel you can obtain great stuff with green and blue, but it's difficult to match the right compliance with reds: you have to play alot with the variables in order to mach an uniform red, for example as background colour.
A pretty nice feature would be the automatic colour correction range, something that plays against the dithering itself, something that says:"every color between #xxxxxx and #yyyyyy belongs to be #$B2 (e.g.) in the very end".
|
|
Posted By
IstvanV
on 2008-04-05
06:49:30
| Re: plus4emu FLI converter
Do you mean color accuracy problems in high resolution modes ? That is a known issue with the algorithm used there, since it basically just does a greyscale conversion and then adds colors, so the luminance has a higher priority than color information. Multicolor FLI modes are implemented differently and are better in this respect, and also allow the user to adjust the relative importance of luminance vs. color. Or is it a different issue than what I was referring to ? Can you post an example that shows the problem ?
|
|
Posted By
Luca
on 2008-04-05
07:11:44
| Re: plus4emu FLI converter
Oh well, it's not a "problem" in the word's meaning.
Simply, I guessed it would be a quite fine feature, forcing a whole range of colours to be performed as one single +4 palette's colour.
I pointed out this is quite useful in case of red, a weak point for the system. Take as an example, a simple red screen: the converter will use dithering in order to match the exact RGB; instead of that, you could simply force it to be plain +4 palette red, avoiding dithering! We may have a complete list of these "brutal forcing", in a separated window:
- from #888888 to #A2A2A2 -> #$41 (midst gray)
- from ...
What do you think about?
|
|
Posted By
Patrick
on 2008-04-05
19:38:33
| Re: plus4emu FLI converter
guys, why i don't have a preview of the image after resizing and calculating? yes, the preview option is on! now i open an image resize it and save and check it out in yape. normal way to it?
|
|
Posted By
Luca
on 2008-04-05
20:09:56
| Re: plus4emu FLI converter
Did you use "PRG with viewer" as output format? Did the converter itself show the converted stuff once you performed the conversion?
|
|
Posted By
Patrick
on 2008-04-05
20:14:50
| Re: plus4emu FLI converter
yes, i used the "PRG with viewer" as output. the conveter didnt show the image after it did his work. i used yape for that...after converting-->save image--->view it in yape..
|
|
Posted By
IstvanV
on 2008-04-05
20:33:08
| Re: plus4emu FLI converter
Patrick: if the preview mode does not work, that means that you either have an old video card without OpenGL 2.0 shader support (which is required by the PAL emulation mode of plus4emu and p4fliconv), or plus4emu - which is needed for the Plus/4 ROM image files and configuration - is not installed. In the latter case, the preview would look like a crashed Plus/4 with garbage displayed. For the first case, I could try building an alternate version of the converter that is more compatible with old machines, at the expense of lower preview quality.
|
|
Posted By
IstvanV
on 2008-04-06
10:21:47
| Re: plus4emu FLI converter
Well, the code should actually have worked even without shader support, and fall back to lower quality, but in practice this was only functional in the emulator, and not the converter. I have a fix for this problem now, although vertical interlace is still not displayed correctly in the converter preview without shaders (there is a picture, but it is too bright). A new p4fliconv.7z file will be uploaded later today.
Luca: OK, I will add this color replacement feature in a later version. Although with the new "pixel exact" reading mode one could also create a pre-dithered image with the Plus/4 palette using an external image editor, the color range mapping might be useful anyway.
|
|
Posted By
IstvanV
on 2008-04-06
18:35:31
| Re: plus4emu FLI converter
The updated package is now uploaded. Other than fixing (mostly) the preview on old video hardware, there are a few minor changes: transparency in .gif and .xpm files is now implemented - transparent pixels are replaced with the border color, .xpm format support is improved somewhat, and the p4sconv utility has a new command line option to set the border color.
|
|
Posted By
IstvanV
on 2008-04-07
12:11:37
| Re: plus4emu FLI converter
Somewhat off-topic: here is a very simple utility that can create Plus/4 palettes in binary or text format, which can be used for example with DFliConv or Dr. Death's flinteractive: http://www.sharemation.com/IstvanV/plus4palette.zip
By default, it saves a palette that is identical to plus4emu in PAL mode with the default settings, but some parameters can be adjusted. For example, with these values, it would reproduce - not exactly, though, due to RGB clipping - the palette of p4fliconv with the default RGB range scale (-0.02 to 1.03) and no color correction: yMax=0.9714, yMin=0.019; this could be useful when comparing the various converters. Another example for an approximation of the YAPE 0.80 palette (some hues, particularly 'green' are different): yMax=0.9333, yMin=0, saturation=0.2133.
About the converter: would it be a good idea to add a link to it on the Tools page ? While it may still need some polishing, it could be already useful enough and has some features that are not in the two converters currently listed there.
|
|
Posted By
Dr. Death
on 2008-04-07
13:09:13
| Re: plus4emu FLI converter
I think this converter surely is developed enough for the tools page
|
|
Posted By
IstvanV
on 2008-04-09
18:39:15
| Re: plus4emu FLI converter
I have created a very simple example program that loads converted images from disk: http://www.sharemation.com/IstvanV/flitest/sample.d64. It is pretty lame, but does show reading and displaying files that were saved in the "raw compressed" format.
|
|
Posted By
Exin
on 2008-04-09
21:15:04
| Re: plus4emu FLI converter
Hi there.
I'm pretty frustrated by now. I really would like to create a picture for a multicolor charset. Interesting is, i load a monochrome (1bit) picture, but after converting, its always pretty grey scaled. Even if the picture dimension is 320x200 or 160x200.
Is there some workaround that i have missed? Anyways, would be lovely if a conversion to Charset would be integrated. (Generated characterset). I know, a software conversion to characterset would be extremely slow. But what the heck. I would even polish the charset with an editor.
With "Amount of characters to be used" please. 
...or at least a function, convert to monochrome (fore and background color) :D
|
|
Posted By
Exin
on 2008-04-09
21:17:30
| Re: plus4emu FLI converter
With scaled, i mean in grayscales. Sorry.
|
|
Posted By
Luca
on 2008-04-10
03:25:55
| Re: plus4emu FLI converter
Exin: Put your "Color Saturation" to 0 and you'll have monochrome.
|
|
Posted By
IstvanV
on 2008-04-10
06:32:41
| Re: plus4emu FLI converter
For conversion to a multicolor character set, you can use the "Logo Editor V2.0 multicolor" mode.
To get 1-bit monochrome black and white output, check "Use 1 bit (black and white) luminance" and set the color saturation multiplier to zero. For this type of conversion, you would probably want to use one of the diffuse dither types, with the limit parameter set to the maximum value.
For the problem of "greyscale output from monochrome input", there are two possible explanations: the new colors may be the result of interpolation (resizing the input image) or dithering. The latter can be avoided by selecting any of the diffuse dither types and setting the limit to zero. To avoid interpolation artifacts, resize the input image with an external image editor to a resolution that is twice that of the standard hires resolution (that is, 640x400 for a normal non-FLI graphics mode, both hires and multicolor), using no interpolation.
There is also a special "pixel exact" image reading mode in the latest version: if the image is in .xpm format, and uses the Plus/4 palette with at least 128 colors and no transparency (the colors do not need to match exactly - it can be a palette from any emulator, but the order within the palette must be correct with no colors missing), then interpolation and color correction are disabled, and the palette is internally replaced with that of the converter.
|
|
Posted By
IstvanV
on 2008-04-10
10:53:52
| Re: plus4emu FLI converter
I noticed that the converted images do not look exactly as they should on my real Plus/4, and made some tests to see if the luma table (which was calculated from the TED documentation, and is also used in YAPE) is correct.
The following table shows the luma levels taken from the TED documentation ("calculated"), as well as those from my real machine (the two "measured" rows, where S is based on the voltage on the S-video output, while C is the composite output, and "Digitized1" is based on a screenshot of the composite output), the "digitized" palette from YAPE (which is based on another real machine), and VICE, all normalized to the same range as in the documentation:
Black 0 1 2 3 4 5 6 7
Calculated: 2.000 2.400 2.550 2.700 2.900 3.300 3.600 4.100 4.800
Measured / S: 2.000 2.437 2.611 2.686 2.921 3.393 3.844 4.096 4.800
Measured / C: 2.000 2.434 2.608 2.681 2.916 3.388 3.840 4.093 4.800
Digitized1: 2.000 2.431 2.600 2.679 2.912 3.387 3.833 4.086 4.800
Digitized2: 2.000 2.419 2.608 2.661 2.881 3.332 3.814 4.087 4.800
VICE: 2.000 2.438 2.613 2.700 2.875 3.400 3.750 4.100 4.800
Note that level 5 in particular seems to be too dark (3.6, while all the others are at least 3.75), and it does actually make a visible difference. So, should I change the palette in the converter and emulator to match more closely the real machines ?
Another color issue: the "green" color has a phase angle of 230 degrees in the current version of YAPE, while it is 240 on my Plus/4 in PAL mode, and 244 in NTSC mode (after conversion to YUV colorspace). In the "digitized" palette of YAPE, it ranges from 236 to 240, and the TED documentation says it is 241 (which is also what I use in the emulator sources). Since the difference between 230 and 241 is visible, I wonder which one is actually correct ?
|
|
Posted By
Gaia
on 2008-04-11
06:48:06
| Re: plus4emu FLI converter
I used to measure different green and luminance values for different machines (I have like 10), I never had the time to figure out the exact reason. It seems there was really a difference between different TED chips as pointed out earlier by not other but Exin himself I guess (at least for the luminance).
And how did you measure? Just because the TED docs have these as luma levels, which are the actual TED pin voltages, while what you're probably measuring on the S-Video output is a not-entirely-linearly transformed luminance signal that went thru some analogue circuitry (this alone could make machine luminances to be different). I used to have a correction for this in Yape, but it turned out to be more confusing than convincing.
|
|
Posted By
IstvanV
on 2008-04-11
09:26:44
| Re: plus4emu FLI converter
Yes, the values shown above are calculated from the voltages measured on the composite and luma outputs. These seem to be fairly consistent with those based on screenshots of the composite output (the largest difference from the measured composite values is 0.008, or about 0.29% of the total range). However, if there is any non-linearity in the video output, that should probably be emulated too, just like in the case of sound.
What would be most useful is to have access to more data from real machines, so any good quality screenshots of measurements are welcome.
In any case, the difference is quite large in the case of the level 5, so it may very well be an error in the documentation, just like the 'dark blue' hue for PAL. I will probably change that to 3.75, but I may also consider using the table from VICE, since it is apparently quite close to my machine.
|
|
Posted By
IstvanV
on 2008-04-11
09:28:30
| Re: plus4emu FLI converter
Sorry, I meant screenshots or measurements, not screenshots of measurements
|
|
Posted By
Gaia
on 2008-04-11
10:37:15
| Re: plus4emu FLI converter
If I recall correctly, the non-linearity was particularly present in the brighter range in there. The luma signal from the TED goes thru an R/F modulator with some resistor network. I know there were several versions of R/F modulators not just TED chips, maybe even the resistor values are different...
See:
http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/plus4/manual/p4-11.gif
|
|
Posted By
IstvanV
on 2008-04-11
12:31:36
| Re: plus4emu FLI converter
It may add some non-linearity, depending also on the characteristics of the TED output, although level 2, 3, and 6 seem to be fairly accurate and consistent, and only 5 differs by a relatively large amount. Of course, it would be possible to test the TED output directly, however, I suspect that it would still not match the documentation. As I mentioned earlier, the most useful information would be data from many different machines.
By the way, the values in the VICE source code seem to make the same assumption as the pepto.de C64 palette, by dividing the black-white range into 32 equal steps, and choosing levels only from those. Although the results seem to be surprisingly similar to what I measured, I do not know why this restriction would actually exist in the hardware, and of course it ignores the possibility for any non-linearity.
|
|
|
Posted By
Luca
on 2008-04-12
10:29:35
| Re: plus4emu FLI converter
Test hardware: Plus/4 PAL, Commodore 1802.
real machine's "colortest_1.prg":
- YAPE (calculated): mediocre, white looks darker, and the gradient is too smooth, whereas in the real machine there's a difference in luma around LUM4;
- YAPE (digitized): very good for lighter greys, a bit worse for darker greys, which appear too smooth in their transition;
- plus4emu (video default): halfaway between YAPE digi and YAPE calc
real machine's "colortest_2.prg":
- YAPE (calculated): quite bad, because YAPE makes it appear extremely smooth;
- YAPE (digitized): good, especially in the midst LUMA greys;
- plus4emu (video default): very bad, especially the "central light column" displayed by the emu.
|
|
Posted By
IstvanV
on 2008-04-12
11:31:26
| Re: plus4emu FLI converter
So, how does it look on your real machine ? I have already seen the images in emulators Or did you mean comparing the real machine to emulators, and found "YAPE digitized" to be most similar ? If that is the case, then I will probably change the palette, since my real machine is also closer to the "digitized" than to the "calculated" palette (see table above).
By the way, colortest_1.prg was generated with the "calculated" palette, and should look as expected (i.e. a smooth linear gradient) with the default plus4emu - use software mode or the highest quality, otherwise the color depth is reduced to 16 bits - or YAPE palette. For colortest_2.prg, I modified the table as follows:
2.00 2.42 2.60 2.70 2.90 3.33 3.75 4.10 4.80
|
|
|
Posted By
Luca
on 2008-04-12
12:57:03
| Re: plus4emu FLI converter
Uh...yes I compared'em with the real machine, I guessed you directly asked for that
|
|
Posted By
IstvanV
on 2008-04-12
13:14:13
| Re: plus4emu FLI converter
OK, sorry for the confusion. So, if I understood correctly then, you found that using YAPE with the digitized palette is closer to the real machine ?
|
|
Posted By
Luca
on 2008-04-12
13:47:11
| Re: plus4emu FLI converter
Yes, not a perfectly fitting one, but closer than others for sure.
|
|
Posted By
Gaia
on 2008-04-12
17:09:19
| Re: plus4emu FLI converter
I checked my sources and I used to have these luma values at one point for the calculated palette:
2.00, 2.4, 2.55, 2.7, 2.9, 3.3, 3.9, 4.3, 4.9
The 4.3 was too bright probably anyway but the 3.9 is close I think. In the end I got sort of fed up with comparing and reverted back to the docs
|
|
Posted By
Exin
on 2008-04-13
22:38:56
| Re: plus4emu FLI converter
Thanks for all the info!
|
|
Posted By
Exin
on 2008-04-17
16:45:55
| Re: plus4emu FLI converter
Anyways, i was looking for a tool that converts to a fullscreen character screen with a modified charset....
|
|
|
Posted By
IstvanV
on 2008-04-19
12:57:39
| Re: plus4emu FLI converter
For testing the palette changes, I have uploaded an emulator executable that uses the modified luma table: http://www.sharemation.com/IstvanV/plus4emu.exe.7z. You can try running the previously posted example programs to see if this version is more consistent with real machines than the original one.
|
|
Posted By
Luca
on 2008-04-19
13:40:01
| Re: plus4emu FLI converter
Tested!
Yes the new palette's colors are very close to the real ones. Their Achilles'Heel is the darker greys: on the real machine you can cleary see a luminance level between two greys in which the whole matter changes radically.
All the rest is very good, especially the "asymmetric video stripes" (one lighter, the mirror opposite one darker) you can see in colortest_2.prg.
Looking forward to the pixel perfect converter feature, I've just chosen some Atari800 pics as specimen ;)
|
|
Posted By
IstvanV
on 2008-04-19
14:20:49
| Re: plus4emu FLI converter
Are the dark greys worse than in the previous version, or better, but still not enough ? How do the screenshots I posted compare to the picture on your machine ?
|
|
Posted By
Luca
on 2008-04-19
15:57:01
| Re: plus4emu FLI converter
The darker greys are better than before, but the difference between LUM4 and LUM3 seems to be very accentuate on the real machine, and not so smooth as the emulation shows.
Weird, your example jpg are smooth too, unlike my Commodore 1802 monitor's output with average contrast set.
Moreover, the emulator "greys" look as tending to a slight purple-grey, instead of plain grey...
The best would be a photo or something...
|
|
Posted By
IstvanV
on 2008-04-19
19:21:05
| Re: plus4emu FLI converter
Well, for now, I updated the converter to use the same modified palette: http://www.sharemation.com/IstvanV/p4fliconv.7z
This version also includes some optimizations in the FLI display code (p4flidisp.s), slightly better support for "pixel exact" conversion in high resolution modes when "optimize for PAL filtering" is disabled, and some other minor changes. Note that the monitor gamma parameter is now interpreted differently, and the default and recommended value is 2.2 (the previous default 1.33 would not look very good now).
|
|
Posted By
Luca
on 2008-04-20
07:27:48
| Re: plus4emu FLI converter
Uhmmm...how to activate the pixel exact feature?
|
|
Posted By
IstvanV
on 2008-04-20
08:51:29
| Re: plus4emu FLI converter
The input file should be in .xpm format, and have a palette that looks similar to the Plus/4 palette, with at least 128 colors and no transparency. Here is a simple example file: http://www.sharemation.com/IstvanV/flitest/test.xpm
Try converting it in high resolution non-interlaced FLI mode; notice that the result is not accurate if "optimize for PAL color filtering" is enabled, so it should be turned off for this type of conversion (older versions were not correct in either mode).
The no transparency limitation could be eliminated (in fact, I have intended to that already, just forgot about it), but the restriction to .xpm format is because the library I use for reading images only preserves the colormap of this format, all others are either converted to RGB or unused colors are removed.
|
|
Posted By
Luca
on 2008-04-20
10:52:06
| Re: plus4emu FLI converter
Ok, I converted an Atari800 pic in a 320x200 .xpm with a 256 (2*128) Photoshop plus/4 palette. Once switched off the PAL optimizing feature, I itred to convert (in MCM of course), but I failed, probably due to the differencies between my palette in *.act format and yours. Apropos, may I have your palette in .act?
|
|
Posted By
IstvanV
on 2008-04-20
11:17:08
| Re: plus4emu FLI converter
The palette should not really matter, unless it is very different so that the picture is not recognized as having a Plus/4 palette. But it would be easier to find out what the problem is if you posted the xpm file.
The PAL optimization trick - and most other "advanced" parameters with the exception of 1-bit luminance, and MC color error scale - is only used in hires modes.
|
|
Posted By
IstvanV
on 2008-04-20
11:54:10
| Re: plus4emu FLI converter
For creating .act palettes, you can use the plus4palette utility that I posted earlier (it is updated to be consistent with the emulator changes). However, accurate color matching without using xpm files is somewhat problematic, since very dark and very light colors are clipped in the RGB colorspace, and the converter would assume incorrect hue for those colors (e.g. $79 instead of $78) unless a low contrast palette is used and the conversion settings are adjusted accordingly.
|
|
Posted By
Luca
on 2008-04-20
12:37:10
| Re: plus4emu FLI converter
Argh! plus4palette.exe produces an .act file which refuses to load into Photoshop
|
|
Posted By
IstvanV
on 2008-04-20
13:11:59
| Re: plus4emu FLI converter
Perhaps because the file only contains 128 colors, rather than 256 ? I have replaced plus4palette.zip with a modified version that writes a 256 color (768 bytes) palette if binary format is selected.
However, I am not sure if different palettes are the reason why you have problems with converting .xpm files (the converter should accept palettes that are only similar to trigger the pixel exact reading mode, as long as all colors are at the correct index, for example 113 is white etc.); could you post an example that does not work as expected ?
|
|
Posted By
Luca
on 2008-04-21
10:22:32
| Re: plus4emu FLI converter
Yes, true: tried the correct palette, and nothing has changed
This is what I tried to perform: I downloaded the winner picture in the Atari gfx compo at Forever 9 party, Neptune's Daughter drawn by Powrooz/Laresistance; then I cutted it 320x200, I assigned my plus/4 palette, then saved as .bmp, converted to .xpm. At this point, I tried to convert it to a regular Plus/4 MCM pic, but this process hasn't performed a pixel exact conversion, due to several dithering workarounds, as if the colours have to be adjusted. Hence, I reduced both dithering values to zero, but the resulting pic was awful and no pixel exact conversion has been performed for the second time.
|
|
Posted By
IstvanV
on 2008-04-21
12:05:49
| Re: plus4emu FLI converter
Try converting this file: http://www.sharemation.com/IstvanV/flitest/f9_neptuned.xpm
Notice that this image is not resized to match the window size exactly in the non-preview mode, and color correction settings are ignored.
If you have problems creating xpm files that are recognized as having the Plus/4 palette, then probably the files are saved with an "optimized" palette that includes only the colors that are actually used, or have a transparent color; in any case, the pixel exact mode is only activated if every palette index in the image can be used directly as a Plus/4 color code.
This alternate image in PNG format is only resized to 640x400 with no interpolation so that image scaling artifacts are avoided: http://www.sharemation.com/IstvanV/flitest/f9_neptuned_640x400.png. It is still converted with color correction and dithering.
|
|
Posted By
Luca
on 2008-04-21
13:25:35
| Re: plus4emu FLI converter
Hence, probably I'd been quite unlucky, choosing this converter.
I'd chosen no transparent color, and this lets me think about an automatic palette stretching by this program...
I've also chosen a strange target picture: it seems to be 288x208, instead of 320x192 as I expected...
|
|
Posted By
IstvanV
on 2008-04-21
13:58:41
| Re: plus4emu FLI converter
I tried the XPMConvert utility, and it does indeed reduce the palette to 18 colors, and I did not find a way to disable this feature. The file I posted above was created with the GIMP; loading an indexed mode .bmp file with it and then simply saving it as .xpm seems to preserve the original palette, although I also used the GIMP to convert the image to the Plus/4 palette. There are probably other utilities that would work, too.
I could also build the converter with a modified version of the FLTK library that does not "optimize" the palette of .gif files (which is the reason why the only format that currently works for pixel exact image reading is .xpm).
|
|
Posted By
Luca
on 2008-04-21
14:17:29
| Re: plus4emu FLI converter
Eh, yeah, must admit, .xpm is not the most usual format in the world...
|
|
Posted By
IstvanV
on 2008-04-21
18:57:49
| Re: plus4emu FLI converter
OK, I have replaced the p4fliconv.7z package with a new version that includes the GIF palette patch. It should hopefully also improve support for transparency.
|
|
Posted By
Luca
on 2008-04-22
09:02:53
| Re: plus4emu FLI converter
Arrrgh, I failed again! 
How to obtain the pixel exact result with a .gif?
|
|
Posted By
IstvanV
on 2008-04-22
10:26:56
| Re: plus4emu FLI converter
Is it possible that the file was saved with the unused entries removed from the palette again ? Also, I only tested transparency with .xpm files before uploading; in the case of .gif, it is still possible to use transparency (for example http://www.sharemation.com/IstvanV/flitest/F7_wally.gif), but it can be tricky depending on which palette index is used as the transparent color. So, unless you really need transparency, it is best avoided when using .gif files.
|
|
Posted By
Luca
on 2008-04-22
10:41:43
| Re: plus4emu FLI converter
Oooh, finally I did by .gif, probably because ACDSee saved a wrong palette for.gif. I tested the 320x200 cutted neptune's daughter and the result is very good, apart some wrong particulars, maybe caused by the machines'differencies in colour attributions once you change the real screen display by cutting sides.
|
|
Posted By
Luca
on 2008-04-22
13:37:2 |
|
Home 
Search 
