To reproduce set the Resize behavior to 'Reduce only', open an image and zoom out or in, then try resizing the window. The image no longer scales, even if the zoom is reset.

Currently it's possible to remap mouse input. Something similar for keyboard input would be nice.

Delete key seems to do nothing in debug build while working in release build. Probably doing something undefined.

The current layout of the "About" setting is getting cramped, so all library licenses should be put in a scrollable text box.

The title says it all, more or less.
Before loading an image, all drop-down lists in the settings dialog act weird. In the current released version, the only noticeable issue is that the mouse-over effect is basically inverted. It's a bigger problem in the dev branch, as it needs to enable/disable a drop-down list and that doesn't work properly (until loading an image).

Weirdest issue I've bumped into in a while.

Pictus is definitely the best image viewer there is - it's lightweight, lightning fast and doesn't contain any unnecessary bloat. However, one feature that it's missing is DDS support. Maybe that's something could be implemented eventually.

Many settings have been visible enough to not really need that, but it can be annoying not knowing if things like new keyboard shortcuts are applied or not.

If a frame in a GIF animation would end up being partially outside the logical display, it will fail rendering past that point. This seems to be undefined in the standard, but firefox seems to handle this by resetting any frame offset.

In both OSX and windows there's a 'fill' option when setting images as wallpaper that centers and scales the image to fit the width of the monitor (if the orientation is portrait) or height (if it's landscape).

It's a useful feature and would be nice to see the same option in Pictus, as often images used for desktop backgrounds are either too large or too small for the existing set wallpaper methods in Pictus and 'Fill' is a good all-rounder.

Folder iteration is done in the GUI thread, which will cause Pictus to be unresponsive during the process. Usually this is fast, but for huge folders (or slow drives) this ends up noticeable and annoying.

Installer download links are forbidden. I think there is a MIME issue for .exe files

The art assets in Pictus are quite horrible and should really be replaced by something a bit more acceptable.

From the top of my head:

• Application icon
• File format icon(s?)
• Pan cursor (seems to be broken now though)

Corel seems to have made a compatibility breaking change at some point. Hopefully it's possible to figure out how to handle these newer files.

Currently PictThumbs does not handle any image format that windows handle out of the box. Might want to reconsider this for JPG files down the road since the built-in thumbnail provider has some issues. Should wait until there's better support for uncommon JPG images though.

If you click on "Apply" or "Ok" in the options dialog while in fullscreen mode and when the status bar is enabled, the text content of the status bar will appear at the bottom. It disappears whenever something triggers a repaint.

Currently Pictus is using Direct3D 9. Since Windows XP support is gone, there's not much preventing an upgrade to Direct3D 11. Vista requires the runtime to be installed, but 7 and newer support it out of the box.

The key "0" should reset zoom.

Although they do make compiles faster, they are proprietary.

libjpeg-turbo is supposed to be API/ABI compatible to the IJG library, so hopefully it'll work out of the box.

There's no automated tests for TIFF as the old pre-github images I had were too large and probably bound by copyright-related restrictions.

It seems that PictThumbs is not properly removed as a thumbnail provider for each file extension (verified on Windows 10). However, the CLSID is removed which will effectively prevent PictThumbs from generating any more thumbnails.

Using existing WIC decoders might add support for a few more formats, but I don't look forward to the bug reports regarding 3rd party decoders (where most seems to be closed source and commercial).

EXIF (and probably other metadata formats) can store the intended display orientation of the image. Fairly commonly used by cameras. Pictus currently doesn't support this, but would be quite nice if it did.

I regularly use Pictus now as the default Photoshop PSD viewer when checking files, however a concern is accidentally pressing the Del key or worse Shift+Del (permanent file deletion), as often these are the original files being viewed.

I'd like to suggest an option to disable these two hidden shortcuts, as although there is already a message prompt, it would be add a bit more of a safeguard when using Pictus as a viewer of important image files.

Compare with this https://chocolatey.org/packages?q=git

It has got.commandline, git.install and git (which combines both depending on them).

So would be good to have Pictus as per se, and optional install integrated into Explorer and registered as searchable program in Start Menu. And possibly one install for auto association with images, or may be pictus.exe into cmd and run "pictus.exe /ext:png,jpg".

So I could script whole install of Pictus onto system via web.

Currently only numeric values can be stored. Will need more flexibility in order to store keyboard shortcut configuration. Looking at Boost.Program_options as this would not break compatibility with current ini files.

Title says it all

Rendering performance drops as images gets larger. Virtual viewport size is based on the image's zoomed size, which is wrong and very inefficient.

These are probably somewhat common and would be a nice start for proper color profile handling.

Updated to 1.5.0 but have noticed a slowdown when opening images. See the attached GIF for a comparison opening/closing the same image between 1.4.0 and 1.5.0 (apologies for the slightly large size). Unsure what has changed that may be causing it. Using the 64-bit versions.

Also upon launch the menus and settings are in a different language (presumably Swedish), even though the Pictus.ini still states English is the set language.

I probably should have split the issues, which I can do if need be.

Just updated to v1.3.0 from 1.2.2 and noticed that during navigation the existing image momentarily stretches to the next image's aspect ratio, something that didn't occur in v1.2.2. Captured some GIFs of it below.

v1.2.2:

v1.3.0:

The current dialog for adjusting images is frankly quite horrible. Not entirely sure how to remake it and it may be dependent on a larger interface overhaul.

illaTest fails when running on ARM:
terminate called after throwing an instance of 'Err::CodecError'
what(): Codec error:
File: UNK_FILE
Line: 0
Function: UNK_FUNC

Description: Error loading JPEG.

This format is fairly obscure and the decoder seems to survive fuzzy testing, but it would still be nice to have some sort of good test data for it. No idea how to get hold of small test-friendly images that I'm allowed to redistribute though.

Currently Pictus creates an .ini file inside appdata. Allowing the .ini to be stored alongside the binary should make Pictus usable as a portable application.

Currently most/all strings are UTF-16.
http://utf8everywhere.org/

Boost.Locale seems competent enough, but it will probably take ages to implement.

In order to fully support all kinds of EXIF orientations, Pictus must be able to flip/mirror rotated images. Rather than adding more states, it's probably a lot neater to split these two concepts.

The BMP file format contains a field that is supposed to indicate the size of the file. Currently Pictus verifies this field to detect potentially broken files, but many programs fill this field with invalid values. Therefore this check should probably be removed.

Should probably add a bunch of additional tests to make sure there's no real negative side effects of this, but the change should be safe enough as the size field is fairly worthless.

This should improve performance slightly and prevent most lost devices (which cause Pictus to crash).

A really cool enhancement would be to have a quick Key / Mouse Button (configurable) to instantly switch between "View Mode" and "Thumbnails Mode" of all the pics inside the current folder.

Let's say we bind Mouse Button 4 to that action. When clicking "Mouse B4" (or other custom assigned Mouse Button / Keyboard Key) the picture will be "swapped" with thumbnails of all the pictures in the working Folder, like an in built browser always set to display Thumbnails. Clicking "Mouse B4" again will simply toggle / return back to the picture we were viewing, while double clicking a thumbnail will return to "View Mode" displaying the double-clicked picture. Hitting "Esc" Key while in "Thumbnails Mode" will also return to the viewed picture. In "Thumbnail Mode" the usual select, copy, delete, hide actions could also be available with modifier Keys (Ctrl, Shift... ) also playing their role in order to multi select, permanent delete, etc. To stretch things further, the "Thumbnails Mode" could also have a Menu/Navigation Bar with the usual Up, Back, Forward and maybe other commands.

Here's some mockups:

Rather than waiting X milliseconds before rendering the next GIF frame Pictus waits X milliseconds before displaying the current one. This may make certain animations to look a bit weird, but also introduces a delay before the first frame becomes visible.

Should make lanczos3 less painful to use.

Since using the new 1.2.0 version I've experienced the two crash dialog messages in a day, although it hasn't been in the middle of viewing images. Unsure what has triggered the crash dialogs, but the last one was after viewing a GIF then closing the window (couldn't reproduce).

Here is the crash dialog error output:

Problem signature:
  Problem Event Name:   BEX64
  Application Name: Pictus.exe
  Application Version:  1.2.0.0
  Application Timestamp:    549897ad
  Fault Module Name:    d3d9.dll_unloaded
  Fault Module Version: 6.3.9600.17095
  Fault Module Timestamp:   534b7c88
  Exception Offset: 000000000000d845
  Exception Code:   c0000005
  Exception Data:   0000000000000008
  OS Version:   6.3.9600.2.0.0.256.48
  Locale ID:    3081
  Additional Information 1: d41d
  Additional Information 2: d41d8cd98f00b204e9800998ecf8427e
  Additional Information 3: 0062
  Additional Information 4: 0062b45507e302fa589ecd5b2f81a5b3

Using the app currently in portable mode, if that makes any difference.

Many words are broken in the Swedish translation due to a file encoding mess-up.

Certain JPEGs display strangely in Pictus. It's rare to come across a JPEG with this issue but reporting it in case the cause can be found.

Side by side comparison (Pictus on left, regular on right):

Example images with the issue:

Flipped 90 degrees and flipped 270 degrees are new (thanks to exif orientation), so might as well expose them to the user.

Found a little bug where if an image is rotated in Pictus 180 degrees panning with the mouse doesn't function. While when rotated 90 / 270 degrees it only pans in one direction.

The current one is simply horrible to manage. Unfortunately I have no idea yet what I should do instead. I don't want any user-facing strings in code, which disqualifies most popular existing systems.

Currently rescaling it's done on CPU. While it does utilize multiple cores and modern CPUs tend to be fairly fast, a GPU approach should be even faster (and thus snappier). This should definitely be noticeable on large displays where Pictus probably won't be able to fully keep up with the refresh rate.