XnView Software

xnview wrote:these files are created by ExifTool as a backup

O.k., that confirms the assumption.

From the user perspective there is XnView MP, only, and it looks as if XnView MP creates these files. I much doubt that these files are wanted by users. Is there a way to surpress these backup files?

xnview wrote:The 0.85 software package was updated. It should be correct, now.

Good to read that this was fixed.

@cday: Thank you for your explanation on "bitness". This helps to understand things better.

After browsing search results for "jpg_original" and the above descriptions it's pretty sure that these files are created by Exiftool.

@Pierre: In which detailed scenario are these file created? Are these files of some use for the XnView user? Is there a way to surpress these files?

Very good that you found the reason for the problem (Microsofts OneDrive), Fritzle! Let's see whether Pierre can do something about this.

Thank you for your bug reports, squeezechart. Could you please use the bug report template and add the missing information? See topic http://newsgroup.xnview.com/viewtopic.php?t=27835

XnTriq wrote: Suggestion for Selection Ratio

Thanks for searching the forum and providing this valuable links. Interesting to read these intensive discussions held 12 years ago.

Fritzle wrote:I tried following: ....

Thank you for your tests, Fritzle. Looks like a(nother) permission problem. I hope that Pierre can track this down and find a solution.

Thank you for this detailed bug report, HanVroon. I could easily reproduce your problem. Your expected behaviour is that XnView navigates to the next existing file as long as there is at least one file in the folder, right?

Reproduced

I can confirm. In most views you get a "Forbidden" cursor but in "Detail view" and "Thumbnails + Details" you can drag&drop with the observed (wrong) behaviour.

Reproduced

@Pierre: I'm not very familiar with "bitness". Is this a serious problem or not so serious? What are the consequences of the wrong bitness?

captaincavern wrote:In 32bit version, BPGDEC.exe and dependencies are 64bit. Same with latest version of XnConvert.

Ouch, that is serious. I guess Pierre will provide a new 0.85 32bit very soon.

Thank you for your bug report and your long term membership in the XnView forum, Markorki. :) I've tried to reproduce your problem with some success: When unchecking " Use embedded thumbnails " in Settings: Browser » Thumbnails and then browsing the directory the info icon "Embedded thumbnail" is no...

Thank you for your extra info, Fritzle. Could you run XnView MP with aministrator rights and see whether it still hangs when browsing? @Pierre: I guess it will be difficult to reproduce this problem. Does the stack trace help you? Could you perhaps provide a special version of XnView MP with trace a...

Thank you for registering here, your kudos, and your bug report, JanFtFA. On which platform do you use XnView MP? Which version of XnView MP do you use? (see Reporting a bug: HowTo and Template ) Does XnView really crash (with or without Kolor crash reporter)? EDIT: I've tried a ftp upload on two ft...

yes image is convert as 8bits per component. Only NConvert can convert 48bits to PNG, TIFF 48bits O.k.. Is there a message box displayed that informs the user? yes when you open it O.k., so it's that XnView doesn't support 48bit images. Support of 48 bit images is a suggestion. :arrow: Suggestions ...