Is there any chance that you could generalize the algorithm?
To be specific, can you generalize the upscaling algorithm such that the given image can be upscaled to any user-chosen power of 2 (or better yet any integer?)
If 2xBRZ upscales an image to twice the length in both directions,
and 3xBRZ upscales an image to three times the length in both directions,
then nxBRZ would upscale an image n times in both directions.
For conventional real-time uses (such as in emulators) high-value vectorization upscaling would be impractical, but would be extremely convenient for pre-rendering (such as images in software development).
Low values are faster and better for realtime,
and higher values produce better images and are suitable for pre-rendering.
You would probably want to make this difference apparent in the supplied readme or help function(command-line)/menu(GUI application)
There are three parts to this question, which would probably be answered in sequence:
1) Is it possible? CAN an algorithm like this be generalized?
2) Is it practical? How much work would it take to do this?
3) How likely is it that this will happen at the current time?
Last edit: oneilmw 2019-11-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) yes
2) computationally expensive, but not too difficult. The result might not be suitable for real-time use, though.
3) not likely. I don't see any demand. Probably 95% of xBRZ use cases are already covered with 2xBRZ - 6xBRZ.
Last edit: Zenju 2019-11-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How do you know that 95% figure? What if there's an unknown but real market for glossy-smooth pixel art blown up to a wall? Can you deny the possibility like that existing? Lots of gamers that were playing in the old days of pixel art are now grown up with walls to decorate. What better than to decorate them with the artwork from their childhood? That's a dangerously decisive (Imagine a judge that was 95% sure) for being in the dark. Like was mentioned elsewhere on the forum, an 8xBRZ would be helpful, and even a 16xBRZ would be cool, but past that would be mostly extreme novelty.
Novelty: I like that word. I think it describes this situation well. I'm still looking for 8xBRZ, though, and a generalization would implement all of this at once.
If it is slower than the non -generalized logic at low multiples, maybe keep them separate programs or dynamically load the faster algorithm for that multiple, or just load the non-generalized one by default and only switch to the generalized one when there isn't a hand-made algorithm for that multiple.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not sure I understand the comic. What do you mean by it? I could privately guess to myself, but I'll give you an opportunity to prevent me from making unfavorable neurological connections.
Also, the comic feels off-topic, but who am I to judge if I can't quite parse it?
Edit: Please don't beat around the bush. I can take it. If I'm somehow a nuisance, please let me know.
Last edit: oneilmw 2019-11-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is there any chance that you could generalize the algorithm?
To be specific, can you generalize the upscaling algorithm such that the given image can be upscaled to any user-chosen power of 2 (or better yet any integer?)
If 2xBRZ upscales an image to twice the length in both directions,
and 3xBRZ upscales an image to three times the length in both directions,
then nxBRZ would upscale an image n times in both directions.
For conventional real-time uses (such as in emulators) high-value vectorization upscaling would be impractical, but would be extremely convenient for pre-rendering (such as images in software development).
Low values are faster and better for realtime,
and higher values produce better images and are suitable for pre-rendering.
You would probably want to make this difference apparent in the supplied readme or help function(command-line)/menu(GUI application)
There are three parts to this question, which would probably be answered in sequence:
1) Is it possible? CAN an algorithm like this be generalized?
2) Is it practical? How much work would it take to do this?
3) How likely is it that this will happen at the current time?
Last edit: oneilmw 2019-11-20
1) yes
2) computationally expensive, but not too difficult. The result might not be suitable for real-time use, though.
3) not likely. I don't see any demand. Probably 95% of xBRZ use cases are already covered with 2xBRZ - 6xBRZ.
Last edit: Zenju 2019-11-20
How do you know that 95% figure? What if there's an unknown but real market for glossy-smooth pixel art blown up to a wall? Can you deny the possibility like that existing? Lots of gamers that were playing in the old days of pixel art are now grown up with walls to decorate. What better than to decorate them with the artwork from their childhood? That's a dangerously decisive (Imagine a judge that was 95% sure) for being in the dark. Like was mentioned elsewhere on the forum, an 8xBRZ would be helpful, and even a 16xBRZ would be cool, but past that would be mostly extreme novelty.
Novelty: I like that word. I think it describes this situation well. I'm still looking for 8xBRZ, though, and a generalization would implement all of this at once.
If it is slower than the non -generalized logic at low multiples, maybe keep them separate programs or dynamically load the faster algorithm for that multiple, or just load the non-generalized one by default and only switch to the generalized one when there isn't a hand-made algorithm for that multiple.
Reminds me of (SCNR) ;)
https://theoatmeal.com/comics/exposure
Last edit: Zenju 2019-11-20
I'm not sure I understand the comic. What do you mean by it? I could privately guess to myself, but I'll give you an opportunity to prevent me from making unfavorable neurological connections.
Also, the comic feels off-topic, but who am I to judge if I can't quite parse it?
Edit: Please don't beat around the bush. I can take it. If I'm somehow a nuisance, please let me know.
Last edit: oneilmw 2019-11-21
its probably a pain in the ass to implement and he gets fuck all from coding it. @oneilmw
if you really want 16x just run xBRZ over the same file twice.