-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing fit scaling alternative in cli version #103
Comments
Hi @magwed. It would be good to add the "fit" functionality aswell to put it in line with the web version. I am a bit reluctant to add more pre-processing to the cli version because:
It should not be very hard to do some pre-processing in your API, with Jimp or otherwise, it's a separate step before using the cli. There is no Web API currently. I have been toying with the idea. The web version now runs 100% on the client browser, but separating it into GUI and API would also help with the GUI headaches :) I am not sure when I can add the 'fit' functionality, but you could check the web sourcecode how it's done and implement it as a pre-processing step. Instead of using the cli, you could also use the core component. The cli and web version both use that. |
Thanks for the comment. Yea I guess I can add this myself to my own fork and you can do as you like. Just for feedback your retropixels is now being used directly from C64 using the open-source project meatloaf which makes it possible to access internet using a virtual IEC-device. By using a special syntax, I'm using retropixels to convert a http-linked image into a executable koala-image, returning and loading it into C64 memory. From a user-perspective you pretty much "load" the JPG-file and show it on-screen. Nice huh? |
That's very nice to hear, that retropixels is actually being used! My suggestion is not to fork retropixels, but to pre-process the image before feeding it into the cli. The reason I want to keep the pre-processing options in the cli to a minimum is that pre-processing like scaling, color manipulation etc. is a separate step from the actual conversion. By keeping it separate you can have control over the pre-processing without being dependent of what options retropixels has to offer. At the same time, the effort put into retropixels can focus on actual conversion instead of generic image manipulation. I plan to add the 'fit' option to the cli soon because I agree it is not "symetrical" with the web version options. |
I have pushed 0.9.10 of the cli version (retropixels), with the added 'fit' option for --scale. Could you give it a spin? |
I tried it and it looks perfect! Portrait images fits right into the landscape C64 original format, great quick fix! I like it! Just one question, what happened to the "-f prg" that I used for my server? -snip- Error: Executable format is not supported for Koala |
Sorry something seems to have broken along the way. If you upgrade to the latest version (0.9.11), it should be fixed. |
Thanks! Now all works for me. Thank you, great work! |
Thanks for a great tool and for sharing!
I have an idea of setting up a hosted Web API to be able to automatically convert images on the fly from C64 itself.
Does the project include a Web API currently?
Your CLI tool seem to be the perfect start of such a project.
I saw that the very useful "fit" scaling property avaiable in the web was missing from CLI and would be most useful to have included.
Also a more full control over JIMP would be cool, like a simple way to control: Contrast, Brightness, Saturation and other parameters from CLI.
The text was updated successfully, but these errors were encountered: