New conversion algorithm

The Oric video chip is not an easy beast to master, so any trick or method that allows to achieve nice visual results is welcome. Don't hesitate to comment (nicely) other people tricks and pictures :)
sam
2nd Star Corporal
Posts: 19
Joined: Sun Jul 09, 2017 3:28 pm
Location: France, Brest
Contact:

Re: New conversion algorithm

Post by sam » Wed Sep 11, 2019 11:36 pm

Okay, I have made the Lua program work in cmd-line in addition to GrafX2 (yes it can do both). Natively it can read 24bits BMP files without compression, but if you have imagemagick's convert command in the path[1], it'll be able to process almost any kind of images. For convenience, a fast Lua interpreter[2] is included in the ZIP.

Usage: <lua-interperter> oric_tst5.lua <filename>.<ext>
  • <lua-intepreter> is the lua interpreter you want to use (LuaJIT.exe for instance under windows)
  • <filename>.<ext> is the full path to the picture you want to convert
It'll produce a <filename>.sap next to the source file. It is an oric sap file with a basic loader.
I'll also produce a <filename>.sap.bmp file next to the source to allow easy viewing of the result without an oric emulator.

Typical usage under Cygwin:

Code: Select all

for i in c:/path/to/folder/*; do ./luajit.exe oric_tst5.lua "$i"; done
I might add later some command-line arguments to enable lauching the emulator on the generated tap file directly, or enable/disable the basic loader, or other things.
___
[1] I did not provide it in the ZIP because it is about 5Mb compressed and I'm not sure the forum can handle such a huge attachment. Pick the one from ImageMagick-7.0.8-64-portable-Q16-x86.zip for windows (exe is ~12Mb, but it can convert almost all files to BMP and is stand-alone).
[2] LuaJIT.exe: a small 32bits exe for windows. Linux guys do usually have LUA already installed or can compile LuaJIT easily.
Attachments
oric_tst5.zip
Now also works in cmd-line too. LuaJIT.exe is included for convenience.
(245.53 KiB) Downloaded 2 times
Last edited by sam on Fri Sep 13, 2019 2:25 pm, edited 5 times in total.

sam
2nd Star Corporal
Posts: 19
Joined: Sun Jul 09, 2017 3:28 pm
Location: France, Brest
Contact:

Re: New conversion algorithm

Post by sam » Thu Sep 12, 2019 2:43 pm

Now with the cmd-line version, I can process a lot of pictures and estimate the robustness of the algorithm :D

So far, it behaves nicely. Of course some pictures are not a "smooth" as I wanted, but I'm not sure if it is an issue with the algorithm or simply that the picture cannot be "smoothly" approximated with Oric's video constaints.

Anyway, here are random results of pictures that I used as reference when working on image conversion for the Thomson's machines[1][2][3] (which explains their 16:10 aspect-ratio).
___
[1] http://www.pouet.net/prod.php?which=61151
[2] http://www.pouet.net/prod.php?which=55979
[3] http://www.pouet.net/prod.php?which=58634
Attachments
0Apple_Wallpaper_2_by_maxwood.tap.png
0Apple_Wallpaper_2_by_maxwood.tap.png (4.58 KiB) Viewed 107 times
158429_Cute-Cat_620.tap.png
158429_Cute-Cat_620.tap.png (5.79 KiB) Viewed 107 times
01090_2008_Lamborghini_Gallardo.tap.png
01090_2008_Lamborghini_Gallardo.tap.png (4.97 KiB) Viewed 107 times

Yicker
Pilot Officer
Posts: 92
Joined: Thu Jan 26, 2006 11:27 pm
Location: St. Helens, Merseyside, UK

Re: New conversion algorithm

Post by Yicker » Thu Sep 12, 2019 4:36 pm

Great work, very impressive.

User avatar
Dbug
Site Admin
Posts: 2942
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: New conversion algorithm

Post by Dbug » Thu Sep 12, 2019 6:02 pm

Nice work, what I'm wondering though is why out of all the possible names in the galaxy, did the two persons who came up with decent conversion algorithm for the Oric have to be named *sam*!

In PictConv I've this:
-f6 => Sam method (Img2Oric)

so if I wanted to integrate this new Algorithm I would have to add something like:
-f8 => Sam method (lua san, not the same Sam)

:)

sam
2nd Star Corporal
Posts: 19
Joined: Sun Jul 09, 2017 3:28 pm
Location: France, Brest
Contact:

Re: New conversion algorithm

Post by sam » Thu Sep 12, 2019 6:45 pm

That's why I usually log in as __sam__, but this forum didn't accept the leading underscore. SamDev is also an option, or Sam/Puls as I am from the Puls demo group.

As far as my tests go, the algorithm works nice. Nothing really bad is produced. It is, in the latest version provided above, good enough for general use. I should now consider porting it to C and maybe sign it as "Sam Sufi" (french joke -- sounds like "this is good enough") :P

From the PictConv sources on github, I found that the other sam's converter is named oric_converter_samhocevar.cpp. So calling mine oric_converter_samueldevulder.cpp would be possible. I'm not well at ease with github dev[1] (except for detecting bugs), but I might write a skeleton of that file with the algorithm and publish here for someone else to test & integrate into github or you can try to indicate me how to build PictConv with MSys2Portable.
___
[1] see this attempt to compile OSDK which miserably failed
Sans titre.png
which makes me look like this in front of my screen
Sans titre2.png
Attachments
Sans titre.png
Sans titre2.png

User avatar
iss
Squad Leader
Posts: 870
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: New conversion algorithm

Post by iss » Thu Sep 12, 2019 7:40 pm

Congrats, sam! Last version works for me and the result is cool.

Just some minor, random, very-Linux-specific thoughts:

- use dos2unix to convert lua source line endings;
- if the first source line is: #!/usr/bin/env lua and chmod +x oric_tst5.lua then you can execute directly from bash:

Code: Select all

./oric_tst5.lua image_file.jpg
- ... and the 'biggest' problem appears - if no path is given then the output file(s) are created in the root / :shock: to fix this I'm using:

Code: Select all

local fullname = path ~= '' and (path .. '/') or '' .. tapname
- about: io.popen(convert,'rb') - unfortunately io.popen 2nd argument is platform depended and for Linux it must be only 'r' - because redirection is always 'binary';

- at end I've tried to use 'convert' to resize input input image to 240x200, changes:

Code: Select all

local convert_resize = 1     -- 1 to use convert to resize input to 240x200
....
....
      local convert = 'convert "' .. filename .. '" '
      -- use external resize
      if 0<convert_resize then
          convert = convert .. '-layers merge -resize 240x200 +repage '
      end
      convert = convert .. '-type truecolor -depth 8 bmp:-'
      bmp = read_bmp24(assert(io.popen(convert,'r')))
....
From this original 'full-color' image the result is:
Lamborghini-Gallardo-9.png
Lamborghini-Gallardo-9.png (11.33 KiB) Viewed 64 times
There are some visual differences but I can't judge which one is better :)

Again well done!

User avatar
Dbug
Site Admin
Posts: 2942
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: New conversion algorithm

Post by Dbug » Thu Sep 12, 2019 8:35 pm

Regarding the OSDK, the official version is actually on my SVN depot, the neko version is a fork where he is doing tests (he works on mac).

I'm going to let you all play with the lua version, and when you are happy, we can convert it to C or C++ and add it as a new method for pictconv, with whatever name you want :)

sam
2nd Star Corporal
Posts: 19
Joined: Sun Jul 09, 2017 3:28 pm
Location: France, Brest
Contact:

Re: New conversion algorithm

Post by sam » Thu Sep 12, 2019 11:12 pm

@iss:

* Convert and internal resize do more or less the same. The difference with the internal version is that it does this in continuous linear-rgb colorspace, preventing issues with gamma-correction. Older version of "convert" do not respect the gamma at all, and newer version quantize the linear colorspace to 8 or 16 bits depending on the version. 8 bits is definitively not enough, 16 might be enough but introduce small quantization errors anyway. Lua working on doubles doesn't suffer from this. Now, the difference between the 2 pictures is very marginal.

* It would be nice to compare the result with the one from pictConv or pipi.exe to see if we get noticeable differences with the existing standards.

* About files being created at /, this is a bug in the code. I blindly add '/' between the path and the name even when path is empty, as you have noticed. Personally I was about to replace the empty path by "." to fix the issue.

[Edit 13/09] I have uploaded a new zip above. It includes fixes for all the things you reported (hopefully) and have some fine-tuned parameters that better suit my corpus (images are less noisy). For those who want to have the convert.exe tool in addition, there is a temporary ZIP >>there<< (cjoint.com).

Post Reply