-
-
Notifications
You must be signed in to change notification settings - Fork 0
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
dgenerate test #3
Comments
I am currently working on adding Stable Cascade support and will include a fix for this. In the meantime the fix is simple and you could add it to your install if desired, I neglected to convert After line 284 of Change the line to: |
This fix works in development, I suspect that I had assumed the temporary fix would work and not tested it myself. I tested this theory by raising a random exception in the edited code, to see if it would throw, it did not throw which means that the edited code is not actually what is running. I am guessing that dgenerates code is actually included in the executable and not modifiable in this way, which means perhaps I do not need to include its sources in the future. That or PyInstaller is storing the bytecode compiled files in some location and they need to be deleted for it to pick up the change. |
This issue should be resolved by https://github.com/Teriks/dgenerate/releases/tag/v3.4.1 |
Please, Can you please make a special version when you are free (when you are available) ? to run only for upcaler models (pth, ckpt..) files. In dgenerate, I tried 'tile size', 'overlap', float32, 16', all of them regarding speed. It lags far behind the chainner. To save space, you can remove old versions of dgenerate v1.0.0, v1.1.0, v0.18.2... from the site. |
On branch https://github.com/Teriks/dgenerate/tree/lite I removed everything except the upscaler image processor and the the image-process subcommand with just enough editing to get it to work, removing un-needed imports etc and then profiling it on my machine import-prof-all.log The all log represents dgenerate with all features, and the image-process log represents dgenerate with just the difference in import time for the dgenerate module when all other features are removed is (3105116us - 2761742us) = 343374us, in effect 0.34 seconds faster start up time which is not a significant improvement. I am guessing the start up time might be worse if you are not running on a fast drive or NVME, or have less processing power in general Most of the overhead is caused by having to load Torch, TorchVision, numpy, and a couple of media libraries that are needed for the models and loading video / images, which could represent around 3.5GB of source all together Your start up time might be much worse than on my machine, where it averages maybe 2-3 seconds before the application fully starts There are probably some improvements to be made to the actual tiling, are you able to determine the start up time of the application vs the actual image processing on your machine? As soon as text is output in the console the application is fully loaded, time spent before then is being spent on loading modules from disk, and time spent after then is actually processing the image I do agree I probably want to remove some of these release artifacts as to not offend github, I am not actually sure what the will tolerate in terms of hosting files |
oh. Thank you very much for lite version. "are you able to determine the start up time of the application vs the actual image processing on your machine?" |
If you do not mind also, what is your use case / workflow for the upscaler plugin? if you are processing many images I might be able to demonstrate a way to automate this process using the built in shell language in a way that does not require launching the application multiple times |
I installed the degenerate lite version but I could not run it. I run different image files with different models. |
You can try I am not sure if config files as described below are actually fully working in that version as it is a quick hack, I mostly just removed a lot of the extra features to see if there would be a speed up in load time, there did not seem to be a drastic effect after profiling If you write (or even generate) a config file for use with the normal version of dgenerate you can do something such as : config.txt
From Windows CMD:
From Powershell:
When running a config file, all processing steps will happen within the same process, avoiding the load time for the modules with every processing step. There are also many things that can be accomplished from the built in shell such as iteration and file globing if needed. If you are running multiple upscaling passes over a single image you can also do this:
Which will process the image with the first upscaler, then process the result with the next upscaler, you can chain as many processing steps together as needed. Here is also an example of using globbing on the directory config.txt
OR:
From Windows CMD:
From Powershell:
When you use dgenerate this way, it should be much faster when running it on many files, the built in shell language is designed for cross platform automation, in a similar way that chaiNNer and ComfyUI use nodes, the idea is that workflows can be described using this script and run without the need for a GUI or even a window manager on your machine. There is a description of the shell language in the readme and some examples in the repository here (config_syntax) and also here (image_process) |
I added |
It worked fine now. dgenerate: 1 minute 20 seconds. 1- Can the lite version be more optimized? 2- Is there a command like ? Can you add. This way, I can activate load_modules and unload_modules and exit degenerate when I'm done.
I can perform my operations between these 2 commands. |
The ability to work with dgenerate without reloading the modules should be covered by the new console UI |
1- I couldn't run the -shell command. Even though I entered twice. dgenerate -shell Could you correct me if it's wrong? How can I give load modules and unload (kill, exit) commands to dgenerate? can you say. 2- because 'dgenerate --console' works faster than the .bat file. 3- What is this and what does it do? dgenerate_windowed.exe |
The shell (dgenerate config language) syntax for image process would be Or:
In the shell language I have written, when a line is not a directive or a template, it is interpreted as arguments for an invocation of dgenerate and you do not need to mention the program name
It is only possible to load the modules into the live dgenerate process, if the process exits all the modules are unloaded when the process dies and there is not a way around this given how python works. So the only way to achieve this sort of usage is to have the process itself be a command shell / interpreter that can handle these tasks in the memory of the running process, instead of the system shell |
You can test if then hit enter twice It should report all of dgenerates argument help text |
dgenerate_windowed.exe is a compiled variant of the dgenerate executable that allows the console UI to launch on Windows through a desktop or start menu shortcut without creating a console window in the background. It’s just for the shortcuts, since Windows makes a distinction about apps compiled as console apps vs GUI apps. It is actually quite annoying that it needs to exist |
I believe there is talk on the spandrel repository of possibly moving their upscaling tiling into the spandrel code base from chainner so that it can be used by consumers of the library. That could help with output similarity in the future, and possibly upscaling performance, since users of the library will be able to reuse their tiled upscaling code directly |
Technically it could be architectured to where the dgenerate command was a client that issued commands to a server in the background similar to docker. I have written the foundations for that to be possible. Just more additional work, I would probably write it as a new project that simply uses what is here to set that all up and offers a new command line tool |
Upon reading a little more I think there is a misunderstanding about it is not meant to be used inside of a bat file, it is a live shell just like cmd so you open a terminal on windows and enter It attaches to your terminal, and you can use it like a system shell (Read Eval Print Loop) It is like launching cmd and typing into it, or like launching the python interpreter without any arguments so that you get an input prompt, it is it’s own shell with its own language and syntax |
The directive / command is I will check into compression. chainner saves its images using cv2 (opencv) if I remember right, I am saving them using PIL (pillow) They may have tweaks for the compression settings upon saving the image in chainner, but I am not sure if the time to save would be drastically different |
\exit I tried something similar but it didn't work. |
It seems better to me to deal with the basic codes of dgenerate. like optimizing and speeding up. |
This is due to |
dtype=float16" error.
dtype=float32" works
The text was updated successfully, but these errors were encountered: