Upscayl fails when using some paths with UTF8 characters
RafaelLinux opened this issue · comments
Checklist
- I have tried ALL of the steps mentioned in the troubleshooting guide.
- I have searched for this in the issues tab.
- My error involves vkEnumeratePhysicalDevices or vkCreateInstance, which means I should ignore the other issues and file this one despite the last checkbox.
Describe the Bug
I upgraded this week to latest AppImage version but now Upscayl fails after processing image.
To Reproduce
- Open Upcayls.AppImage
- Drag and drop JPG image
- Click in "UPSCAYL" button (all default configuration)
Upscayl Version (or commit hash)
v210.0
Platform
Linux
OS Version
openSUSE Tumbleweed 20240404
GPU Name
AMD Radeon RX 7600
Expected Behavior
To get upscaled image.
Screenshots
Logs
🚧 UPSCAYL_PROGRESS: 99.71%
🐞 BACKEND REPORTED: 💯 Done upscaling
🐞 BACKEND REPORTED: ♻ Scaling and converting now...
🐞 BACKEND REPORTED: 📐 Processing Image: {"originalWidth":2975,"originalHeight":4463,"customWidth":null,"scale":"2","saveImageAs":"png","compressionPercentage":0,"compressionLevel":0}
🐞 BACKEND REPORTED: 🖼️ Checking if original image exists: /home/Imágenes/#Día 3/Ciclistas.jpeg
🐞 BACKEND REPORTED: ❌ Error processing (scaling and converting) the image. Please report this error on GitHub. Error: Input file is missing: /home/Imágenes/#Día 3/Ciclistas_upscayl_2x_ultrasharp.png
🔄 Resetting image paths
🔄 Resetting image paths
⤵️ Dropped file: {"type":"image/jpeg","filePath":"/home/Imágenes/#Día 3/Ciclistas.jpeg","extension":"jpeg"}
🖼 Setting image path: /home/Imágenes/#Día 3/Ciclistas.jpeg
🗂 Setting output path: /home/Imágenes/#Día 3
🖼 imagePath: /home/Imágenes/#Día 3/Ciclistas.jpeg
🔤 Extension: jpeg
⚙️ Getting saveImageAs from localStorage: png
⚙️ Getting model from localStorage: {"label":"General Photo (Ultrasharp)","value":"ultrasharp"}
⚙️ Getting gpuId from localStorage: AMD
⚙️ Getting rememberOutputFolder from localStorage: false
It could be the non-english alphabets in the path. Could you try something like /home/temp/?
Confirmed. It works in a simple path like /run/media/user/2GB_FAT/
I'll see if it's fixable. Does upscayl-ncnn output anything or is the error only for the post-processing step?
Info I attached is from LOG when it try to finish (99,71%).
For sure it's fixable cause I have a lot of folders with that kind of characters and applications have no issues about that.
Does the file /home/Imágenes/#Día 3/Ciclistas_upscayl_2x_ultrasharp.png exist?
No. I needed to move "Ciclistas.jpg" to /mnt/USB_2GB and process it there
Woah, I'll take a look. Thanks for the ping
I think this is fixed in latest Upscayl-NCNN update.
$ ./build-arm64/upscayl-bin -i "images/Imágenes #Día 3.jpg" -o "output/Imágenes #Día 3.jpg" -s 6 -m models -n realesrgan-x4fast -f jpg
🚀 Starting Upscayl - Copyright © 2024
✨ Detected scale x4
[0 Apple M1] queueC=0[1] queueG=0[1] queueT=0[1]
[0 Apple M1] bugsbn1=0 bugbilz=0 bugcopc=0 bugihfa=0
[0 Apple M1] fp16-p/s/a=1/1/1 int8-p/s/a=1/1/1
[0 Apple M1] subgroup=32 basic=1 vote=1 ballot=1 shuffle=1
0.00%
25.00%
50.00%
75.00%
🏞️ Resizing image according to output scale
🏞️ Resized image from 300x300 to 1800x1800
100.00%
🙌 Upscayled Successfully!@RafaelLinux could you please try upscaling the image with the latest version of upscayl-ncnn via the terminal?
./upscayl-bin -i "/home/Imágenes/#Día 3/Ciclistas.jpeg" -o "/home/Imágenes/#Día 3/Ciclistas_upscayl_2x_ultrasharp.png" -s 2 -m models -n realesrgan-x4plus -f pngWhere can I download upscayl-ncnn?
I tried with another image, but similar path (I have not previous image yet in JPEG, but in JXL).
./upscayl-bin -i "/home/Imágenes/#Dia 2/Franjas de color.jpeg" -o "/home/Imágenes/#Dia 2/Ciclistas_upscayl_2x_ultrasharp.png" -s 2 -m models -n realesrgan-x4plus -f png
🚀 Starting Upscayl - Copyright © 2024
✨ Detected scale x4
[0 AMD Radeon RX 7600 (RADV NAVI33)] queueC=1[4] queueG=0[1] queueT=0[1]
[0 AMD Radeon RX 7600 (RADV NAVI33)] bugsbn1=0 bugbilz=82 bugcopc=0 bugihfa=0
[0 AMD Radeon RX 7600 (RADV NAVI33)] fp16-p/s/a=1/1/1 int8-p/s/a=1/1/1
[0 AMD Radeon RX 7600 (RADV NAVI33)] subgroup=64 basic=1 vote=1 ballot=1 shuffle=1
fopen /home/bin/upscayl-bin-20240406-160311-linux/models/realesrgan-x4plus.param failed
fopen /home/bin/upscayl-bin-20240406-160311-linux/models/realesrgan-x4plus.bin failed
find_blob_index_by_name data failed
Try
find_blob_index_by_name output failed
Try
0.00%
....
....
find_blob_index_by_name data failed
Try
find_blob_index_by_name output failed
Try
98.96%
🏞 Resizing image according to output scale
🏞 Resized image from 2246x1500 to 4492x3000
Abortado (`core' generado)
@RafaelLinux Try finding a core dump according to the instructions at https://www.suse.com/support/kb/doc/?id=000020900
@TGS963 Do you have any experience with core dumps?
@RafaelLinux Try finding a core dump according to the instructions at https://www.suse.com/support/kb/doc/?id=000020900
@TGS963 Do you have any experience with core dumps?
Yes I've debugged using core dumps for smaller programs. Not sure how helpful it'll be for larger programs like this though
I tried with another image, but similar path (I have not previous image yet in JPEG, but in JXL).
./upscayl-bin -i "/home/Imágenes/#Dia 2/Franjas de color.jpeg" -o "/home/Imágenes/#Dia 2/Ciclistas_upscayl_2x_ultrasharp.png" -s 2 -m models -n realesrgan-x4plus -f png 🚀 Starting Upscayl - Copyright © 2024 ✨ Detected scale x4 [0 AMD Radeon RX 7600 (RADV NAVI33)] queueC=1[4] queueG=0[1] queueT=0[1] [0 AMD Radeon RX 7600 (RADV NAVI33)] bugsbn1=0 bugbilz=82 bugcopc=0 bugihfa=0 [0 AMD Radeon RX 7600 (RADV NAVI33)] fp16-p/s/a=1/1/1 int8-p/s/a=1/1/1 [0 AMD Radeon RX 7600 (RADV NAVI33)] subgroup=64 basic=1 vote=1 ballot=1 shuffle=1 fopen /home/bin/upscayl-bin-20240406-160311-linux/models/realesrgan-x4plus.param failed fopen /home/bin/upscayl-bin-20240406-160311-linux/models/realesrgan-x4plus.bin failed find_blob_index_by_name data failed Try find_blob_index_by_name output failed Try 0.00% .... .... find_blob_index_by_name data failed Try find_blob_index_by_name output failed Try 98.96% 🏞 Resizing image according to output scale 🏞 Resized image from 2246x1500 to 4492x3000 Abortado (`core' generado)
Do you have the models in the models directory?
Also, JXL is not supported I think.
Do you have the models in the models directory? Also, JXL is not supported I think.
I have no idea what are the "models" or that directory, sorry. Yes, I know JXL is not supported, that's why I changed source file to another still in JPG. But I'll suggest - in another thread - to add JXL option to export to JXL ;)
You need to extract the files into the same directory where you extracted Upscayl or copy Upscayl's models folder over. Should be somewhere in /usr/share/upscayl
Hello again. I was reading the link to do the "core dump" but it was getting complex.
I preferred to do an isolated test, with a simpler path but with UTF8 characters that are supported by all the applications I use in Plasma. I think it is easy to replicate in any Linux if you create a path with the same name, so I include again the LOG content after having done the test in a very short path but with UTF8 characters in it (not in the filename).
⚙️ Getting saveImageAs from localStorage: png
⚙️ Getting model from localStorage: {"label":"General Photo (Real-ESRGAN)","value":"realesrgan-x4plus"}
⚙️ Getting gpuId from localStorage: AMD
🔀 Setting model to
🔀 Setting model to realesrgan-x4plus
🐞 BACKEND REPORTED: 💾 Updating Save Output Folder: false
🐞 BACKEND REPORTED: 📐 Updating Compression: 0
⚙️ Getting saveImageAs from localStorage: png
⚙️ Getting model from localStorage: {"label":"General Photo (Real-ESRGAN)","value":"realesrgan-x4plus"}
⚙️ Getting gpuId from localStorage: AMD
⚙️ Getting rememberOutputFolder from localStorage: false
🔄 Resetting image paths
⤵️ Dropped file: {"type":"image/jpeg","filePath":"/run/media/myuser/2GB_FAT/#Día 5/Image.jpg","extension":"jpg"}
🖼 Setting image path: /run/media/myuser/2GB_FAT/#Día 5/Image.jpg
🗂 Setting output path: /run/media/myuser/2GB_FAT/#Día 5
🖼 imagePath: /run/media/myuser/2GB_FAT/#Día 5/Image.jpg
🔤 Extension: jpg
⚙️ Getting saveImageAs from localStorage: png
⚙️ Getting model from localStorage: {"label":"General Photo (Real-ESRGAN)","value":"realesrgan-x4plus"}
⚙️ Getting gpuId from localStorage: AMD
🔀 Setting model to
🔀 Setting model to realesrgan-x4plus
🔄 Resetting Upscaled Image Path
🏁 UPSCAYL
🐞 BACKEND REPORTED: 🖼️ Updating No Image Processing: false
🐞 BACKEND REPORTED: 📐 Updating Compression: 0
🐞 BACKEND REPORTED: Is Default Model? : true
🐞 BACKEND REPORTED: ✅ Upscayl Variables: {"model":"realesrgan-x4plus","gpuId":"AMD","saveImageAs":"png","inputDir":"/run/media/myuser/2GB_FAT/#Día 5","outputDir":"/run/media/myuser/2GB_FAT/#Día 5","fullfileName":"Image.jpg","fileName":"Image","initialScale":"4","desiredScale":"2","outFile":"/run/media/myuser/2GB_FAT/#Día 5/Image_upscayl_2x_realesrgan-x4plus.png","compression":0}
🐞 BACKEND REPORTED: 📢 Upscayl Command: -i,/run/media/myuser/2GB_FAT/#Día 5/Image.jpg,-o,/run/media/myuser/2GB_FAT/#Día 5/Image_upscayl_2x_realesrgan-x4plus.png,-s,4,-m,/tmp/.mount_Upscayo9tIBA/resources/models,-n,realesrgan-x4plus,-g,AMD,-f,png
🐞 BACKEND REPORTED: 👶 Updating Child Processes: {"binary":"/tmp/.mount_Upscayo9tIBA/resources/bin/upscayl-bin","args":["/tmp/.mount_Upscayo9tIBA/resources/bin/upscayl-bin","-i","/run/media/myuser/2GB_FAT/#Día 5/Image.jpg","-o","/run/media/myuser/2GB_FAT/#Día 5/Image_upscayl_2x_realesrgan-x4plus.png","-s","4","-m","/tmp/.mount_Upscayo9tIBA/resources/models","-n","realesrgan-x4plus","-g","AMD","-f","png"]}
🐞 BACKEND REPORTED: 🛑 Updating Stopped: false
🐞 BACKEND REPORTED: image upscayl: [0 AMD Radeon RX 7600 (RADV NAVI33)] queueC=1[4] queueG=0[1] queueT=0[1]
[0 AMD Radeon RX 7600 (RADV NAVI33)] bugsbn1=0 bugbilz=82 bugcopc=0 bugihfa=0
[0 AMD Radeon RX 7600 (RADV NAVI33)] fp16-p/s/a=1/1/1 int8-p/s/a=1/1/1
[0 AMD Radeon RX 7600 (RADV NAVI33)] subgroup=64 basic=1 vote=1 ballot=1 shuffle=1
🚧 UPSCAYL_PROGRESS: [0 AMD Radeon RX 7600 (RADV NAVI33)] queueC=1[4] queueG=0[1] queueT=0[1]
[0 AMD Radeon RX 7600 (RADV NAVI33)] bugsbn1=0 bugbilz=82 bugcopc=0 bugihfa=0
[0 AMD Radeon RX 7600 (RADV NAVI33)] fp16-p/s/a=1/1/1 int8-p/s/a=1/1/1
[0 AMD Radeon RX 7600 (RADV NAVI33)] subgroup=64 basic=1 vote=1 ballot=1 shuffle=1
🐞 BACKEND REPORTED: image upscayl: 0.00%
🚧 UPSCAYL_PROGRESS: 0.00%
...
🐞 BACKEND REPORTED: image upscayl: 99.15%
🚧 UPSCAYL_PROGRESS: 99.15%
🐞 BACKEND REPORTED: 💯 Done upscaling
🐞 BACKEND REPORTED: ♻ Scaling and converting now...
🐞 BACKEND REPORTED: 📐 Processing Image: {"originalWidth":2508,"originalHeight":1672,"customWidth":null,"scale":"2","saveImageAs":"png","compressionPercentage":0,"compressionLevel":0}
🐞 BACKEND REPORTED: 🖼️ Checking if original image exists: /run/media/myuser/2GB_FAT/#Día 5/Image.jpg
🐞 BACKEND REPORTED: ❌ Error processing (scaling and converting) the image. Please report this error on GitHub. Error: Input file is missing: /run/media/myuser/2GB_FAT/#Día 5/Image_upscayl_2x_realesrgan-x4plus.png
🔄 Resetting image paths
⚙️ Getting saveImageAs from localStorage: png
⚙️ Getting model from localStorage: {"label":"General Photo (Real-ESRGAN)","value":"realesrgan-x4plus"}
⚙️ Getting gpuId from localStorage: AMD
⚙️ Getting rememberOutputFolder from localStorage: false
BTW the entire models folder thing can be simplified to replacing Upscayl the GUI's upscayl-bin with the one you downloaded
Please test v2.11 Prerelease
Bad news. Apparently, process end successfully. However, re-scaled image is not showed in right side of side-by-side comparison and the new file doesn't exist in original folder (or anywhere).
⚙️ Getting saveImageAs from localStorage: png
⚙️ Getting model from localStorage: {"label":"General Photo (Real-ESRGAN)","value":"realesrgan-x4plus"}
⚙️ Setting gpuId to empty string
🔀 Setting model to
𝌖 BACKEND REPORTED: 📁 Updating Output Folder Path: "/home/mnt/#Dia 2"
🔀 Setting model to realesrgan-x4plus
🔄 Resetting image paths
⤵️ Dropped file: {"type":"image/png","filePath":"/home/mnt/#Dia 2/Colores RGB.png","extension":"png"}
🖼 Setting image path: /home/mnt/#Dia 2/Colores RGB.png
🗂 Setting output path: /home/mnt/#Dia 2
🖼 imagePath: /home/mnt/#Dia 2/Colores RGB.png
🔤 Extension: png
🔄 Resetting Upscaled Image Path
🏁 UPSCAYL
𝌖 BACKEND REPORTED: 🖼️ Updating No Image Processing: false
𝌖 BACKEND REPORTED: 📐 Updating Compression: 0
𝌖 BACKEND REPORTED: Is Default Model? : true
𝌖 BACKEND REPORTED: ✅ Upscayl Variables: {"model":"realesrgan-x4plus","gpuId":null,"saveImageAs":"png","inputDir":"/home/mnt/#Dia 2","outputDir":"/home/mnt/#Dia 2","fullfileName":"Colores RGB.png","fileName":"Colores RGB","scale":"2","outFile":"/home/mnt/#Dia 2/Colores RGB_upscayl_2x_realesrgan-x4plus.png","compression":0}
𝌖 BACKEND REPORTED: 📢 Upscayl Command: -i,/home/mnt/#Dia 2/Colores RGB.png,-o,/home/mnt/#Dia 2/Colores RGB_upscayl_2x_realesrgan-x4plus.png,-s 2,-m,/tmp/.mount_Upscay8ko0f9/resources/models,-n,realesrgan-x4plus,-f,png
𝌖 BACKEND REPORTED: 👶 Updating Child Processes: {"binary":"/tmp/.mount_Upscay8ko0f9/resources/bin/upscayl-bin","args":["/tmp/.mount_Upscay8ko0f9/resources/bin/upscayl-bin","-i","/home/mnt/#Dia 2/Colores RGB.png","-o","/home/mnt/#Dia 2/Colores RGB_upscayl_2x_realesrgan-x4plus.png","-s 2","-m","/tmp/.mount_Upscay8ko0f9/resources/models","-n","realesrgan-x4plus","-f","png"]}
𝌖 BACKEND REPORTED: 🛑 Updating Stopped: false
𝌖 BACKEND REPORTED: image upscayl: 🚀 Starting Upscayl - Copyright © 2024
🚧 UPSCAYL_PROGRESS: 🚀 Starting Upscayl - Copyright © 2024
𝌖 BACKEND REPORTED: image upscayl: ✨ Detected scale x4
🚧 UPSCAYL_PROGRESS: ✨ Detected scale x4
𝌖 BACKEND REPORTED: image upscayl: [0 NVIDIA GeForce RTX 2060] queueC=2[8] queueG=0[16] queueT=1[2]
[0 NVIDIA GeForce RTX 2060] bugsbn1=0 bugbilz=0 bugcopc=0 bugihfa=0
[0 NVIDIA GeForce RTX 2060] fp16-p/s/a=1/1/1 int8-p/s/a=1/1/1
[0 NVIDIA GeForce RTX 2060] subgroup=32 basic=1 vote=1 ballot=1 shuffle=1
[1 llvmpipe (LLVM 16.0.5, 256 bits)] queueC=0[1] queueG=0[1] queueT=0[1]
[1 llvmpipe (LLVM 16.0.5, 256 bits)] bugsbn1=0 bugbilz=0 bugcopc=0 bugihfa=0
[1 llvmpipe (LLVM 16.0.5, 256 bits)] fp16-p/s/a=1/1/1 int8-p/s/a=1/1/1
[1 llvmpipe (LLVM 16.0.5, 256 bits)] subgroup=8 basic=1 vote=1 ballot=1 shuffle=1
🚧 UPSCAYL_PROGRESS: [0 NVIDIA GeForce RTX 2060] queueC=2[8] queueG=0[16] queueT=1[2]
[0 NVIDIA GeForce RTX 2060] bugsbn1=0 bugbilz=0 bugcopc=0 bugihfa=0
[0 NVIDIA GeForce RTX 2060] fp16-p/s/a=1/1/1 int8-p/s/a=1/1/1
[0 NVIDIA GeForce RTX 2060] subgroup=32 basic=1 vote=1 ballot=1 shuffle=1
[1 llvmpipe (LLVM 16.0.5, 256 bits)] queueC=0[1] queueG=0[1] queueT=0[1]
[1 llvmpipe (LLVM 16.0.5, 256 bits)] bugsbn1=0 bugbilz=0 bugcopc=0 bugihfa=0
[1 llvmpipe (LLVM 16.0.5, 256 bits)] fp16-p/s/a=1/1/1 int8-p/s/a=1/1/1
[1 llvmpipe (LLVM 16.0.5, 256 bits)] subgroup=8 basic=1 vote=1 ballot=1 shuffle=1
𝌖 BACKEND REPORTED: image upscayl:
🚧 UPSCAYL_PROGRESS:
𝌖 BACKEND REPORTED: image upscayl: 0.00%
🚧 UPSCAYL_PROGRESS: 0.00%
...
𝌖 BACKEND REPORTED: image upscayl: 🏞️ Resized image from 320x307 to 640x614
🚧 UPSCAYL_PROGRESS: 🏞️ Resized image from 320x307 to 640x614
𝌖 BACKEND REPORTED: 💯 Done upscaling
𝌖 BACKEND REPORTED: ♻ Scaling and converting now...
upscaledImagePath: /home/mnt/#Dia 2/Colores%20RGB_upscayl_2x_realesrgan-x4plus.png
💯 UPSCAYL_DONE: /home/mnt/#Dia 2/Colores%20RGB_upscayl_2x_realesrgan-x4plus.png
⚙️ Getting saveImageAs from localStorage: png
⚙️ Getting model from localStorage: {"label":"General Photo (Real-ESRGAN)","value":"realesrgan-x4plus"}
⚙️ Setting gpuId to empty string
```
Could you try upscayling an image in non-external storage, e.g. in /home/Imágenes?
Ok, I found the issue. It's mostly related to encoding and decoding URI component. Oh boy, this is going to take a lot of refactoring 😰
Should be fixed in v2.11
@RafaelLinux Would you kindly try again? :)
What's version number to download??
The latest
No changes. Exactly same behaviour remains in ver 2.11.0
No changes. Exactly same behaviour remains in ver 2.11.0
Are you sure? I just tested with the same path and it works fine.
I've done more and more tests, as I pointed out at the subject of this thread, it is the NON ASCII characters (UTF8 characters) that Upscayl does not handle correctly. In different languages the alphabet incorporates ‘á à ç ñ’. If the path contains any of these characters, Upscayl fails.
Update: This path should work for Upscayl #áçèïñ (all applications I use in Linux can work on that path, LibreOffice, GIMP, Okular, Gwenview, ....). I even checked working on this path using AppImage version of applications like XNView or Converseen to be sure issue is not AppImage versions related.
I've done more and more tests, as I pointed out at the subject of this thread, it is the NON ASCII characters (UTF8 characters) that Upscayl does not handle correctly. In different languages the alphabet incorporates ‘á à ç ñ’. If the path contains any of these characters, Upscayl fails.
Update: This path should work for Upscayl
#áçèïñ(all applications I use in Linux can work on that path, LibreOffice, GIMP, Okular, Gwenview, ....). I even checked working on this path using AppImage version of applications like XNView or Converseen to be sure issue is not AppImage versions related.
I'll test on Linux. Mac seems to work just fine.
Perhaps it happens only on SUSE?
Yeah, I'm unable to reproduce it on other operating systems or distros. I'm closing the issue because it seems machine specific.
PS: I'd recommend downloading Upscayl v2.11 again because I changed the binaries with a fix later.
At some point in the conversation there has been a misunderstanding. I always referred to the name of the path, not the files. The name of the file has never seemed to be a problem, but THE PATH (in my example "#áçèïñ").
From the beginning, this thread has referred to the path in its title, I don't understand how the problem has become related to the filename.
Things do not change (in my testing) and should not change just because we tested the bug in the filename instead of the pathname. Also note that the path in #770 (comment) doesn't contain any non-ascii chars either.
Things do not change (in my testing) and should not change just because we tested the bug in the filename instead of the pathname.
After the tests I have been carrying out, I think the subject of this thread would be more appropriately ‘NON-ASCII characters’ in the route. In my examples, there were always some non-ASCII characters in the paths. I am not aware of any problems with such characters in the filenames.
And it is not a problem of my operating system because I have taken the trouble to test with other programs (all mentioned) in the same path and with the same file, exporting with the same ones to that path, and none of them had problems.
Also note that the path in #770 (comment) doesn't contain any non-ascii chars either.
Yes, there were specifically 2 NON-ASCII characters in the route, although especially the ‘í’ can go unnoticed. Whenever the problem has occurred, it has always been in routes that included NON-ASCII characters.
I can't contribute more, because this thread has been closed as if the problem was not reproducible because the tests have been limited to the file name, and a folder has not been created with the sequence of characters that I have found to fail.
Thanks anyway
Things do not change (in my testing) and should not change just because we tested the bug in the filename instead of the pathname.
After the tests I have been carrying out, I think the subject of this thread would be more appropriately ‘NON-ASCII characters’ in the route. In my examples, there were always some non-ASCII characters in the paths. I am not aware of any problems with such characters in the filenames.
And it is not a problem of my operating system because I have taken the trouble to test with other programs (all mentioned) in the same path and with the same file, exporting with the same ones to that path, and none of them had problems.
Also note that the path in #770 (comment) doesn't contain any non-ascii chars either.
Yes, there were specifically 2 NON-ASCII characters in the route, although especially the ‘í’ can go unnoticed. Whenever the problem has occurred, it has always been in routes that included NON-ASCII characters.
I can't contribute more, because this thread has been closed as if the problem was not reproducible because the tests have been limited to the file name, and a folder has not been created with the sequence of characters that I have found to fail.
Thanks anyway
I tested with the exact same paths as yours, unfortunately was unable to reproduce the issue.
I apologize for the trouble, but I cannot really fix something I can't encounter :(
Something of note is that the logs say /home/mnt/#Dia 2/Colores RGB.png.
Something of note is that the logs say /home/mnt/#D_i_a 2/Colores RGB.png.
Yeah, still can't reproduce.
Something of note is that the logs say /home/mnt/#D_i_a 2/Colores RGB.png.
Yes, it is very clear that in one of the occasions (1 of 6) in which I have mentioned the route, it did not include "strange" characters. That just means that when searching and replacing - for privacy, of course - text strings in the logs, I made a mistake and replaced one of those characters as well. Of course, if you insist on proving precisely with the example that did not meet the premise of the subject of this thread, there will be no bug to corroborate, because it won't happen, of course.
I do not insist. I guess that with luck, some non-English speaking user who gets to use Upscayl in folders that use characters from their own alphabet might notice the problem and perhaps report it (that's a long shot, so I'm afraid the bug will be around for a long time to come).
Also, my sincere thanks for paying attention to my notification.
Regards
Something of note is that the logs say /home/mnt/#D_i_a 2/Colores RGB.png.
Yeah, still can't reproduce.
That was the right way to check it, thank you. The path and even the name with the commented character sequence. However, I think the bug only occurs on Linux (and maybe only with the AppImage version). Again, I remind you that this is Linux and that none of the other programs mentioned fail on the same path and file. What's more, in the first tests it was an EXt4 file system and in the last ones on FAT32 (a mounted pendrive, so as not to have to change in the logs text containing private information).
We've also tested #áçèïñ on Linux.
Something of note is that the logs say /home/mnt/#D_i_a 2/Colores RGB.png.
Yeah, still can't reproduce.
That was the right way to check it, thank you. The path and even the name with the commented character sequence. However, I think the bug only occurs on Linux (and maybe only with the AppImage version). Again, I remind you that this is Linux and that none of the other programs mentioned fail on the same path and file. What's more, in the first tests it was an EXt4 file system and in the last ones on FAT32 (a mounted pendrive, so as not to have to change in the logs text containing private information).
I tested the latest AppImage on Linux too. I was unable to reproduce the bug. That's why I said that it might be device specific, try some other distro maybe.