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.

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.

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

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.

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")

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

* 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).