A long time ago I examined the "classic" image to track converter, the one that was by
MaxwellNurzia, written in python, and taken down eventually. It wasn't very fast and had a few bugs (namely one that forced the image to be rendered left to right, not up to down). After writing a few "line art" demos in golang, I wrote a new image converter in C++ as a demo, and quickly made it into a library for interacting with tracks. That's why the demo tracks I put out vary a lot, because my API has facilities for vector art and raster art. It didn't take long to write, the track code is pretty simple once you figure out how it works.
Anyway, from my experience, C++ is just the best for this type of thing. One of the only reasons that the FRHD's javascript online app works so well for general purpose tracks is because the map is represented in terms of sectors (similar to Minecraft's "chunks"). However, in terms of performance with more dense tracks (like image converted ones), this method doesn't work out the best. And even then, the app is locked at 30fps so that can give you a good idea of the efficiency of this way.
So basically what I'm getting at is that if you want a fast image to track converter, you really need to do it in a close-to-the-metal language, like C++ or even better, C. I don't know about MATLAB, but hearing about "8-bit unsigned integers" is a good sign in terms of how performant it is. Python and even GoLang are too slow in this respect. However, if it floats your boat, you can use those languages, but keep in mind that your track-making pipeline will bottleneck at image to track conversion, and not loading the tracks into FRHD like is is for me.
And
octo believe it or not, there is some handwritten x86 assembly in the library I use for the image parsing. (but I didn't write it because I'm an x86 noob)
Click to expand...