Closed szotsaki closed 4 years ago
It seems it's also possible to reproduce it when you add a Unicode character into the file name itself which non-English Windows versions do when they create a copy of a file into the same directory the original file resides.
(Ps.: if fixing this bug significantly hinders Qt migration, I'd opt for skipping this issue since after Qt handles paths, Unicode won't be a problem anymore.)
I already fixed this bug - keep an eye out for 4.2.5 in a day or so.
David
Thank you for the fix. I've tried 4.2.5 and opening files indeed works; however, saving the final TIFF is not possible when the path contains non-ASCII characters.
Interestingly, when only the filename itself contains those characters, the operation succeeds now but with a strange result. It seems like it either uses a wrong code-page or trying to double encode the name. An example for this:
Eredmény.TIF
→ EredmĂ©ny.TIF
Thanks for letting me know. I'm sorry, the fix was incomplete, and was done for reading but not for writing.
I hope you can live with not using accented characters for output files as I'm not doing a new release any time soon.
No problem, fortunately there are plenty of workarounds available :).
When there's a Unicode (non-ASCII) character in the path name, DeepSkyStacker won't do anything after selecting that directory to save the resulting TIFF file to with "Save picture to file...".
When the output directory is configured to be of the reference frames and those frames are in a directory with Unicode characters, the processed image is lost, and the result window is gray.
Also a similar case, when opening specific files (like specifically dark, or flat, or bias, etc.) from these kind of paths, the files won't be added to the list. Interestingly, it works from the "Open picture files..." command.
A sample path with Unicode characters:
C:\Users\Árvíztűrő\Pictures\Csillagfotózás
.DSS version: 4.2.4.