-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
[BUG][PATH PARSING] Cannot upscayl Non-ASCII path #802
Comments
Huh, interesting. #770 mentions the same bug but I was unable to reproduce it. Using lámpara as the directory name caused the error on Linux. On MacOS, It's not the case, the image upscayls just fine. |
I think it was very hasty to close my thread, and I don't understand why. I have tested on two different computers, with different versions of Tumbleweed (6 months without updating one of them) and the problem occurred on both of them. Also, I was previously using Upscayl without problems in folders with non-ASCII characters, so if suddenly after an update of Upscayl, it stops working properly, I think it is clear that some change in Upscayl causes the problem, and even more when all the other applications work in those folders with the same files without problems. For my part, I have again taken the trouble to check from which version some change in the Upscayl code caused this problem to occur and I have found out that it is the versions after 2.9.8 that fail. Interestingly, version 2.9.9 at least gave an error (not like the latest version, which tells the user that ‘everything is fine’). In 2.9.9 it shows this error:
It shows an error about Upscayl is not able to find same file was processing. I even tried to test the install version (RPM) but I couldn't, because it doesn't find the libuuid library (in openSUSE, it's libuuid1). Of course, in any way I can help you find out what's going on by providing more information or testing, please let me know. |
@RafaelLinux I only closed the other thread because I was unable to reproduce the issue with your provided paths on Linux. This issue however, mentioned another name which I was able to reproduce the bug with. |
I'll investigate more |
That's because in 2.9.9 we pointed a separate tool to the file path to post-process it. We later infused processing into our own CLI which tries to output it all in one go. |
I expect it helps in some way. |
@NayamAmarshe Upscayl fails to save and display upscaled images when the output folder contains non-ASCII characters on Linux due to issues with path handling. The
This function ensures that non-ASCII characters are percent-encoded, which should handle most cases correctly [1]. Additionally, logging and debugging information in versions 2.10.9 and 2.11 can provide more insight. The For further investigation, ensure that all paths, including the output folder path, are sanitized using the
|
This bot has completely ignored the fact that this problem has arisen from an update of Upscayl and did not happen before under the same conditions. Therefore, mentioning to the end user that a possible solution is to sanitise the route using certain functions is totally absurd. Only the developer really knows what changes there have been between versions to cause something to fail now that worked before. |
Hey @RafaelLinux valid feedback! We want to support and are actively working on improving Dosu's triage bugs via recent changes, so stay tuned :) |
I don't think it did that. It only mentioned me and I called the bot to investigate the issue for me. |
It seems that setting the output folder to a non-ASCII path works. The problem is with upscayl-ncnn somewhere and it' strange. It's able to read the input directory but not able to write to the same directory with non-ASCII directory. Also, the file being non-ASCII does not seem to matter, it's only the directory here that's causing the issue. (gdb) run -i ./lámpara/#áçèïñ.jpg -o ./lámpara/hrllo.png -m ./resources/models/ -n 'realesrgan-x4fast' -f png
Starting program: /home/user/Public/upscayl/resources/linux/bin/upscayl-bin -i ./lámpara/#áçèïñ.jpg -o ./lámpara/hrllo.png -m ./resources/models/ -n 'realesrgan-x4fast' -f png
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
🚀 Starting Upscayl - Copyright © 2024
✨ Detected scale x4
✨ Using the default scale x4
[0 NVIDIA GeForce GTX 1660 SUPER] queueC=2[8] queueG=0[16] queueT=1[2]
[0 NVIDIA GeForce GTX 1660 SUPER] bugsbn1=0 bugbilz=0 bugcopc=0 bugihfa=0
[0 NVIDIA GeForce GTX 1660 SUPER] fp16-p/s/a=1/1/1 int8-p/s/a=1/1/1
[0 NVIDIA GeForce GTX 1660 SUPER] subgroup=32 basic=1 vote=1 ballot=1 shuffle=1
[1 llvmpipe (LLVM 15.0.7, 256 bits)] queueC=0[1] queueG=0[1] queueT=0[1]
[1 llvmpipe (LLVM 15.0.7, 256 bits)] bugsbn1=0 bugbilz=0 bugcopc=0 bugihfa=0
[1 llvmpipe (LLVM 15.0.7, 256 bits)] fp16-p/s/a=1/1/1 int8-p/s/a=1/1/1
[1 llvmpipe (LLVM 15.0.7, 256 bits)] subgroup=8 basic=1 vote=1 ballot=1 shuffle=1
[New Thread 0x7fffe5bff640 (LWP 22640)]
[New Thread 0x7fffe53fe640 (LWP 22641)]
[New Thread 0x7fffe4bfd640 (LWP 22642)]
[New Thread 0x7fffd7fff640 (LWP 22644)]
[New Thread 0x7fffcffff640 (LWP 22671)]
[New Thread 0x7fffcf7fe640 (LWP 22672)]
[New Thread 0x7fffceffd640 (LWP 22673)]
[New Thread 0x7fffce7fc640 (LWP 22674)]
[New Thread 0x7fffcdffb640 (LWP 22675)]
[New Thread 0x7fffcd7fa640 (LWP 22676)]
[New Thread 0x7fffccff9640 (LWP 22677)]
[New Thread 0x7fffc7fff640 (LWP 22678)]
[New Thread 0x7fffc77fe640 (LWP 22679)]
[New Thread 0x7fffc6ffd640 (LWP 22680)]
[New Thread 0x7fffc67fc640 (LWP 22681)]
[New Thread 0x7fffc5ffb640 (LWP 22682)]
[New Thread 0x7fffc57fa640 (LWP 22709)]
[New Thread 0x7fffc4ff9640 (LWP 22710)]
[New Thread 0x7fffbffff640 (LWP 22711)]
[New Thread 0x7fffbf7fe640 (LWP 22712)]
[New Thread 0x7fffbeffd640 (LWP 22713)]
[Thread 0x7fffbffff640 (LWP 22711) exited]
[Thread 0x7fffc57fa640 (LWP 22709) exited]
0.00%
25.00%
100.00%
50.00%
75.00%
100.00%
[Thread 0x7fffbeffd640 (LWP 22713) exited]
[Thread 0x7fffc4ff9640 (LWP 22710) exited]
Thread 21 "upscayl-bin" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffbf7fe640 (LWP 22712)]
__pthread_kill_implementation (no_tid=0, signo=6, threadid=140736406218304) at ./nptl/pthread_kill.c:44
44 ./nptl/pthread_kill.c: No such file or directory. |
backtrace:
The error is happening in the save(void*) function. |
@aaronliu0130 He's busy, I'll be fixing the code :) |
The issue was with Upscayl NCNN. To fix the issue, I did these things:
|
Also discovered a bug in Nautilus where dragging a file with # in the name into the terminal causes the # to disappear. |
Checklist
Describe the Bug
If the path that contains the destination folder, or the folder itself, has non-ascii characters in the name, the program fails to save and show the enlarged image. The logs say the image has been processed correctly and report it as saved in the selected path, but the image is not saved (or shown in the UI) unless an output folder without non-ascii characters in the name or path is selected. The log does not display any errors. By all accounts, the image should be saved but it's not, and the UI does not display it.
To Reproduce
lámpara
orcañón
.Upscayl Version (or commit hash)
2.10.9 and 2.11
Platform
Linux
OS Version
Arch Linux (using both AUR and AppImage)
GPU Name
AMD Lexa PRO (Radeon RX 550X rev. c7)
Expected Behavior
The image should be saved correctly in any folder with write permissions.
Screenshots
Logs
The text was updated successfully, but these errors were encountered: