Just saw on Slashdot that "Two researchers — Johannes Kopf from Microsoft, and Dani Lischinski from The Hebrew University — have successfully created an algorithm that depixelizes and upscales low-resolution 8-bit 'pixel art' into lush vector graphics."
Details can be found here and here.
This leads me to the following question:
Would it be possible to implement such a feature into SCUMMVM at some point, to add interest from new gamers who don't see the beauty of old graphics but would like to enjoy a chance to play Maniac Mansion or Beneath a Steel Sky? It seemingly worked for the two Monkey Island remakes, and there doesn't seem to be any new versions on their way with the loss of Darrell Rodriguez as the president of LucasArts...
I know this wouldn't be possible to implement any time soon, but would the developers consider adding it eventually?[/url][/quote]
Upscaling Retro 8-Bit Pixel Art To Vector Graphics
Moderator: ScummVM Team
-
DrMcCoy
- ScummVM Developer
- Posts: 595
- Joined: Sat Dec 17, 2005 1:33 pm
- Location: Braunschweig, Germany
- Contact:
Re: Upscaling Retro 8-Bit Pixel Art To Vector Graphics
Possible? Probably.Duffadash wrote:Would it be possible to implement such a feature into SCUMMVM at some point
There's a few caveats, however:
The ScummVM graphics system currently has no idea about vector graphics, so a vector renderer would need to be added too. This would take quite some works and increase the code complexity and size.
And the algorithm as it currently is is far too slow for real-time graphics, with a median of 0.62s per frame (see Results in the paper).
I have to say this is the first "upscaling" algorithm that I find convincing. I never played a game with hq4x or similar solutions because to me graphics look worse in my eyes after applying these filters. I guess there is a way to speed up this algorithm and should some coder outside ScummVM be able to optimize it for real-world use I'd be happy to see it implemented. And thanks for the links, interesting read.
From what I've read in the posts from the authors, there's a lot of comparison to other upscalers, like 2xSaI, so I doubt the inner workings of the algorithm are all that different, and from what I've been able to gather, ScummVM uses 2xSaI, hq2x, hq3x and others as upscalers. Surely this wouldn't be hard to implement too?
Though I might be wrong, since the speed IS slow... Maybe in a daily build for testing or something?
Though I might be wrong, since the speed IS slow... Maybe in a daily build for testing or something?
The fact that they compare their results with those of existing scalers is only natural, but does *NOT* imply that their algorithm works in a similar fashion.
Indeed, it does not at all work in a similar fashion, but rather is vastly more complex. Please read the full paper if you want to discuss this, don't pull guesses out of ... thin air.
One major difference is for example that all our existing scalers work with local information: They look at a small subsection of the image (from 1x1 to 3x3 pixels) and then decide based upon that, how to generate output. This new algorithm looks at the whole image at once, which is a major difference in many ways.
It also produces vector graphics,; and involves computations of things like voronois cells and (smoothed) spline approximations, and for this also requires data structures for effectively representing these. All of the ingredients they use are well-known and understand by people working on algorithmic geometry, but that doesn't make them simple or even trivial...
Lastly, the paper is not at all detailed enough to make an independent implementation of their algorithm; too many rather crucial details are missing for that. Not that I am complaining, for this kind of paper, this is quite normal and OK; they describe the high level approach, the rest are "implementation details", which are not important if you want to understand the thing in general, and maybe come up with your own ideas for improvements. But for implementations, they *are* important
.
Indeed, it does not at all work in a similar fashion, but rather is vastly more complex. Please read the full paper if you want to discuss this, don't pull guesses out of ... thin air.
One major difference is for example that all our existing scalers work with local information: They look at a small subsection of the image (from 1x1 to 3x3 pixels) and then decide based upon that, how to generate output. This new algorithm looks at the whole image at once, which is a major difference in many ways.
It also produces vector graphics,; and involves computations of things like voronois cells and (smoothed) spline approximations, and for this also requires data structures for effectively representing these. All of the ingredients they use are well-known and understand by people working on algorithmic geometry, but that doesn't make them simple or even trivial...
Lastly, the paper is not at all detailed enough to make an independent implementation of their algorithm; too many rather crucial details are missing for that. Not that I am complaining, for this kind of paper, this is quite normal and OK; they describe the high level approach, the rest are "implementation details", which are not important if you want to understand the thing in general, and maybe come up with your own ideas for improvements. But for implementations, they *are* important
.Yes, it works with vector graphics, but I may have missed it while reading, or it wasn't even there:
I thought it outputs raster files?
Even if it works with vector algorithms, I don't think that's important, IF the final results are in raster. I think the real problem here is it's speed.
But IF the output of the software is something similar to vector graphics like SVG, then it gets more complicated.
I thought it outputs raster files?
Even if it works with vector algorithms, I don't think that's important, IF the final results are in raster. I think the real problem here is it's speed.
But IF the output of the software is something similar to vector graphics like SVG, then it gets more complicated.
The output of the algorithm is vector data, but of course any vector data can rastered, using a rasterizer.
If their implementation of the algorithm produces raster data as final result, then it does so by using a rasterizer.
But anyway, this is really about the easiest part of it all (well, not completely trivial either, but fast vector rasterizers exist aplenty and the employed techniques fairly well-known.
If their implementation of the algorithm produces raster data as final result, then it does so by using a rasterizer.
But anyway, this is really about the easiest part of it all (well, not completely trivial either, but fast vector rasterizers exist aplenty and the employed techniques fairly well-known.
The algorithm is far too slow...
Indeed, the output quality is excellent...
The output is vector data...
And fast vector rasterizers do exist...
Well, can you imagine an off-line tool which just creates a new package with high-quality vector graphic into? It should take, you say, data from monkey island 1 files and then creates a `mk1.pkg' which contains shiny new vector graphics generated from the original packages (the conversion will work on that ugly old font also!!!). This way I really don't care about conversion time, it can even take a week!
And finally, a recent build of scummvm with a fast rasterizer will render the graphics at my preferred resolution (you say, even 932x699 with no need of opengl) with flawless details, reading only data from this new `mk1.pkg'.
What about this? This would be a classic scenario I can figure scummvm involved with.
Indeed, the output quality is excellent...
The output is vector data...
And fast vector rasterizers do exist...
Well, can you imagine an off-line tool which just creates a new package with high-quality vector graphic into? It should take, you say, data from monkey island 1 files and then creates a `mk1.pkg' which contains shiny new vector graphics generated from the original packages (the conversion will work on that ugly old font also!!!). This way I really don't care about conversion time, it can even take a week!
And finally, a recent build of scummvm with a fast rasterizer will render the graphics at my preferred resolution (you say, even 932x699 with no need of opengl) with flawless details, reading only data from this new `mk1.pkg'.
What about this? This would be a classic scenario I can figure scummvm involved with.
I can imagine a company like LucasArts pulling that off, who pays lots of developers to work full time on such a project. Oh wait, they did something like that already, only they paid artists to create new artwork ... .
But seriously: Of course almost everything is possible. What you describe is possible in principle. It's just a truckload of work. If a couple dedicated and talented developers were to work on this full time for some months, I am sure they could pull it all off, but this is *way* beyond the scope of ScummVM. Completely. Totally. Absolutely
.
.But seriously: Of course almost everything is possible. What you describe is possible in principle. It's just a truckload of work. If a couple dedicated and talented developers were to work on this full time for some months, I am sure they could pull it all off, but this is *way* beyond the scope of ScummVM. Completely. Totally. Absolutely
.Ok, ok.fingolfin wrote:It's just a truckload of work. [...] but this is *way* beyond the scope of ScummVM. Completely. Totally. Absolutely
Scummvm was born to play adventure games and it will keep on doing this. The issue with the new scenario would only be: adding a rasterizer.
Then, talking about development, the huge part is into the conversion and that `off-line tool' should be a brother/sister/son/daughter/someway related (but untied) project only aimed at conversion.
Finally, I can figure out this will end up in a new line into the `Feature requests' page on sourceforge!
Come on people, get back on Earth. This algorithm is nice, but there is very long way from current state to realtime processing. There are different potential routes to optimizing it, but I personaly woudn't like that scummvm team wastes time on such task (fortunately they are wise enough not to do someones homework). I don't know why are you pushing this huge amount of work on shoulders of Scummvm developers? I'm tired of people who come to these forums with crazy ideas and no knowledge about developing process, and claim that this should be easy, and should be done by scummvm folks (preferably right now).
Anyway, scummvm is open for new enthusiastic people - if you feel that such feature is easy-made and widely needed - join the team. And if you say that you're no programmer, then spare us your ideas and focus on helping scummvm in other way - by testing for example.
Anyway, scummvm is open for new enthusiastic people - if you feel that such feature is easy-made and widely needed - join the team. And if you say that you're no programmer, then spare us your ideas and focus on helping scummvm in other way - by testing for example.
