dgenerate test

[rahmirtrt]

dtype=float16" error. dtype=float32" works

[Teriks]

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 the image Tensor to the correct data type for the model.

After line 284 of dgenerate\\imageprocessors\upscaler.py (In the _internal folder for windows installs, or site-packages for a pip install)

Change the line to: in_img = torchvision.transforms.ToTensor()(image).unsqueeze(0).to(self.modules_device, dtype=self._dtype)

[rahmirtrt]

I changed this line and I got the error again.

[Teriks]

This fix works in development, I suspect that dgenerate.exe is not executing the edited code due to the way PyInstaller works even though it is included as a source package under _internal.

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.

[Teriks]

This issue should be resolved by https://github.com/Teriks/dgenerate/releases/tag/v3.4.1

[rahmirtrt]

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. Thus Let it be separated from everything else. It needs to be fast and not wait before starting the process.

In dgenerate, I tried 'tile size', 'overlap', float32, 16', all of them regarding speed. It lags far behind the chainner. Sample time for a file I tested; chainner: 55 seconds dgenerate: 1 minute 20 seconds. There shouldn't be that much difference.

To save space, you can remove old versions of dgenerate v1.0.0, v1.1.0, v0.18.2... from the site.

[Teriks]

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 import-pro-image-process.log

The all log represents dgenerate with all features, and the image-process log represents dgenerate with just --sub-command image-process and the upscaler image processor

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

[rahmirtrt]

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?" ok. I can run the .bat file, view it with the pause command, and determine it by keeping a stopwatch.

[Teriks]

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

[rahmirtrt]

I installed the degenerate lite version but I could not run it. gave this error.

I run different image files with different models. similar to dgenerate --sub-command image-process tmp2.jpg --output tmp2u.png -al 1 --processors "upscaler;model=4x_Real_SSDIR_DAT_GAN.pth" after dgenerate --sub-command image-process xc.jpg --output tmp2u.png -al 1 --processors "upscaler;model=4x_Real_SSDIR_DAT_GAN.pth" after dgenerate --sub-command image-process vvp2.jpg --output tmp2u.png -al 1 --processors "upscaler;model=1x_dn_grl_small_c3s50.ckpt" after dgenerate --sub-command image-process 2.jpg --output tmp2u.png -al 1 --processors "upscaler;model=4xSSDIRDAT.pth" after dgenerate --sub-command image-process t5.jpg --output tmp2u.png -al 1 --processors "upscaler;model=4xFaceUpLDAT.pth" after ...... ........

[Teriks]

You can try pip install tqdm to fix this, it is missing the progress bar dependency, I probably accidentally removed it. I do remember I needed to install it manually but I must have forgotten to add it back

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

\image_process tmp2.jpg --output output_dir/ -al 1 --processors "upscaler;model=4x_Real_SSDIR_DAT_GAN.pth"

\image_process xc.jpg --output output_dir/ -al 1 --processors "upscaler;model=4x_Real_SSDIR_DAT_GAN.pth"

\image_process vvp2.jpg --output output_dir/ -al 1 --processors "upscaler;model=1x_dn_grl_small_c3s50.ckpt"

\image_process 2.jpg --output output_dir/ -al 1 --processors "upscaler;model=4xSSDIRDAT.pth"

\image_process t5.jpg --output output_dir/ -al 1 --processors "upscaler;model=4xFaceUpLDAT.pth"

From Windows CMD:

dgenerate < config.txt

From Powershell:

Get-Content config.txt | dgenerate

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:

dgenerate --sub-command image-process tmp2.jpg --output tmp2u.png -al 1 --processors "upscaler;model=4x_Real_SSDIR_DAT_GAN.pth" "upscaler;model=4xFaceUpLDAT.pth"

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 my_images

config.txt

{% for file in glob.iglob('my_images/*.png') %}
   \image_process {{ quote(file) }} -al 1 --output output_dir/ --processors "upscaler;model=4xFaceUpLDAT.pth"
{% endfor %} !END

OR:

\set myfiles {{ quote(glob.glob('my_images/*.png')) }}

\image_process {{ myfiles }} -al 1 --output output_dir/ --processors "upscaler;model=4xFaceUpLDAT.pth"

From Windows CMD:

dgenerate < config.txt

From Powershell:

Get-Content config.txt | dgenerate

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)

[Teriks]

I added tqdm to the lite branch and commited one other fix that prevented the upscaler from working, you can attempt to reinstall it. I can only guarantee that the command itself works

[rahmirtrt]

It worked fine now. _internal folder size 4.06 gb --> lite version 3.71 gb dgenerate.exe 61.780 mb --> lite version 29.789 mb

dgenerate: 1 minute 20 seconds. dgenerate lite version: 1 minute 10-16 seconds. 5-7 seconds faster.

1- Can the lite version be more optimized?

2- Is there a command like ? Can you add. From Windows CMD: dgenerate < load_modules (ready for processing) dgenerate < unload_modules (unload_modules and Exit from dgenerate)

This way, I can activate load_modules and unload_modules and exit degenerate when I'm done.

1. load_modules
2. unload_modules and exit from dgenerate

I can perform my operations between these 2 commands. When I'm done, I can unload, exit from dgenerate.

[Teriks]

The ability to work with dgenerate without reloading the modules should be covered by the new console UI —console and shell mode —shell mode which allows you to use dgenerate like a shell. The corresponding directive in the shell would be \image_process, the —shell mode requires hitting enter twice to submit a command

[rahmirtrt]

1- I couldn't run the -shell command. Even though I entered twice. I used these commands in the .bat file.

dgenerate -shell dgenerate --sub-command image-process tmp2.bmp --output tmp3ssu.png -al 1 --processors "upscaler;model=4x_Real_SSDIR_DAT_GAN.pth" pause

Could you correct me if it's wrong?

How can I give load modules and unload (kill, exit) commands to dgenerate? can you say. dgenerate --shell _start_shell_process dgenerate --shell start (load) dgenerate --shell exit (unload) .......... .......

2- because 'dgenerate --console' works faster than the .bat file. Despite all this, chainner is faster.

3- What is this and what does it do? dgenerate_windowed.exe

[Teriks]

The shell (dgenerate config language) syntax for image process would be \image_process tmp2.bmp --output tmp3ssu.png -al 1 --processors "upscaler;model=4x_Real_SSDIR_DAT_GAN.pth"

Or:

--sub-command image-process tmp2.bmp --output tmp3ssu.png -al 1 --processors "upscaler;model=4x_Real_SSDIR_DAT_GAN.pth"

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

\image_process is a config directive that maps to the subcommand image-process, which does the same thing but just look’s a little clearer syntactically

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

[Teriks]

You can test if dgenerate —shell is functioning properly by waiting to be able to type (may not be able to type anything until modules load fully), then typing \help (show help directive)

then hit enter twice

It should report all of dgenerates argument help text

[Teriks]

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

[Teriks]

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

[Teriks]

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

[Teriks]

Upon reading a little more I think there is a misunderstanding about dgenerate —shell

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 dgenerate —shell

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

[Teriks]

The directive / command is \exit or \exit (your return code)

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

[rahmirtrt]

\exit \exit 15 \exit (15) \exit {15}

I tried something similar but it didn't work.

[rahmirtrt]

It seems better to me to deal with the basic codes of dgenerate. like optimizing and speeding up. The rest is that important. It seems like a waste of time to me. Maybe additional onnx and ncnn support can be added.

[Teriks]

\exit \exit 15 \exit (15) \exit {15}

I tried something similar but it didn't work.

This is due to exit being used instead of sys.exit in the code for the \exit directive which may of happened from InjelliJ optimizing imports, should be fixed in the branch I am working on which is mostly just syntax high lighting for the console. You should be able to still mash Ctrl-C to exit the process in the current version