Recent Posts

1

Support and Feedback / Icon tooltip for Create new tab/Restore closed tab is not displayed

« Last post by JBG2963 on Yesterday at 22:10:17 »

The tooltip for the Create new tab/Restore closed tab is not displayed while hovering over the icon.

Thank you for a great app!!

2

Feature Requests and Suggestions / Re: Folder Paths - Copy or enter

« Last post by Mathias (Author) on October 08, 2026, 19:33:43 »

Menu > Tools > To Clipboard, also the toolbar icon next to the 'eye' icon.. the clipboard with c:\ click on that to copy path, right click on it for more options

I think default shortcut for some of them is Ctrl+P and Ctrl+Shift+P, but it is shown there

3

Support and Feedback / Re: Folder Refreshes

« Last post by Mathias (Author) on October 08, 2026, 19:31:29 »

I can't replicate that, Is it network folder. ? some network system have issue with notifying window that the filesystem is change.

4

Support and Feedback / Folder Refreshes

« Last post by ssheen on October 08, 2026, 17:38:23 »

I noticed that the right folder list does not refresh if another app has modified files in the list.

Thanks

5

Feature Requests and Suggestions / Folder Paths - Copy or enter

« Last post by ssheen on October 08, 2026, 17:34:48 »

I may of missed this if it exists already, but if not, it would be nice to be able to copy the folder path, as well as paste or type it.

Thanks

6

Support and Feedback / Re: Bug in image viewer

« Last post by Mathias (Author) on October 04, 2026, 16:24:59 »

I don't this so as long as it fits into memory.

7

Support and Feedback / Re: Bug in image viewer

« Last post by nietrupek on October 04, 2026, 15:27:07 »

Is there any restriction on image dimension in  WIC? I have some very tall images and all but one are displayed by image viewer:
610x10789 - OK
540x16635 - fails

I don't think it is metada problem because rewriting file using my favourite tool (exiftool) doesn't help.
WebView displays image correctly.

8

Support and Feedback / Re: Bug in image viewer

« Last post by nietrupek on October 03, 2026, 16:50:53 »

Microsoft reader is a bit to strict. yes reading a value that is expected as SHORT as LONG can be a problem. But only if the value read actual is larger then MAX SHORT value. and this value can only be 0-6

No, value can be even MAX_SHORT - 1. This is the best and most detailed documentation I am aware of:
https://exiftool.sourceforge.net/TagNames/EXIF.html#Compression
It was created in 2005 and is refined and updated for 21 years.

But I guess Microsoft just follow the spec very strict.

However for the next version.. If it fails to loading an image because of metadata.. It will retry loading it without metadata.

Kudos to Microsoft. They SHOULD be strict. Years ago they added their own "enhancenents" everywhere, making a mess in programming world. Glad they stopped.

If you accept the suggestion: please show at least warning informing user that his file is problematic. If not, even a red dot in menu area would be better than nothing.

9

Support and Feedback / Re: Bug in image viewer

« Last post by Mathias (Author) on October 03, 2026, 11:36:26 »

Microsoft reader is a bit to strict. yes reading a value that is expected as SHORT as LONG can be a problem. But only if the value read actual is larger then MAX SHORT value. and this value can only be 0-6
But I guess Microsoft just follow the spec very strict.

However for the next version.. If it fails to loading an image because of metadata.. It will retry loading it without metadata.

10

Support and Feedback / Re: Bug in image viewer

« Last post by nietrupek on October 03, 2026, 04:50:12 »

[IFD1 (thumbnail)] at offset 64, 3 entries
  0x0103 Compression                  LONG      count=1     inline   (6,) <-- WRONG TYPE, expected SHORT
  0x0201 JPEGInterchangeFormat        LONG      count=1     inline   (106,)
  0x0202 JPEGInterchangeFormatLength  LONG      count=1     inline   (1891,)

All clear now. I simply misunderstood your previous post. I was looking for KEY 0x0103 as LONG while you meant its VALUE (6). So, your AI was right. Here they are:

00000a0  00  03  01  04  00  01  00  00  00  06  00  00  00  01  02  04
00000b0  00  01  00  00  00  6a  00  00  00  02  02  04  00  01  00  00


If someone is interested how to repair such files: as JPEG compression is lossy, we must re-write matadata only while leaving image data intact.

This command reads metadata and writes them back:
c:> exiftool -all= -tagsfromfile @ -all:all -unsafe -icc_profile  plomyki.jpg

The result is attached. Viewer shows it properly.

Thank you for your support. I definitely learned something new.