Simple Image Viewer

[WhoCares]

Manual image view + Auto image slideshow + Background music playback.
Powered by Rust + egui.
Windows/macOS/Linux

https://github.com/z16166/SimpleImageViewer

[wx69wx2023]

I like to use acdsee32 , version 2.43, the old one in 2000 year , just 1M,
I do not know why the acdsee32 is too big now.

[WhoCares]

The last release in the classic ACDSee line was 2.44. The reason ACDSee grew in size over time is pretty simple: it kept accumulating image editing and processing features.

Other image viewers worth mentioning include FastStone Image Viewer, IrfanView, ImageGlass, FastPictureViewer, qView, and XnView MP. Some of these are Windows-only, while others are cross-platform. Under the hood, some rely on GDI/GDI+, while others leverage GPU acceleration.

My project, Simple Image Viewer, is built on egui with GPU rendering. It’s cross-platform and primarily focused on slideshow-style viewing for browsing images. With more time, I plan to extend support for additional image formats—especially the many RAW formats out there.

Originally Posted by wx69wx2023

I like to use acdsee32 , version 2.43, the old one in 2000 year , just 1M,
I do not know why the acdsee32 is too big now.

[WhoCares]

v0.9.8

1. Gigapixel image support — tiled rendering engine for 100MP+ images
2. PSD / PSB support — native Photoshop reader with custom PSB streaming parser and RAM safety check

Tested with the following big images from NASA, downloaded from https://esahubble.org/images/viewall/:

https://esahubble.org/static/images/zip/top100/top100-original.zip

v1.2.2
1. light/dark theme
2. i18n support, 4 languages(en/zh-CN/zh-HK/zh-TW)
3. image printing
4. Win7 x64 support
5. drag-n-drop

[WhoCares]

major update v2.0.0+

HDR-capable rendering:

HDR-oriented presentation when the file carries HDR or extended brightness range;
how strong it looks depends on an HDR-capable display monitor and whether system HDR is enabled.

supported HDR file formats:

Ultra HDR JPEG and JPEGs with HDR metadata
Radiance HDR (.hdr)
OpenEXR (.exr)
JPEG XL (.jxl)
AVIF / AVIFS
HEIF / HEIC / HIF
TIFF encodes that retain extended range / higher bit depth

HDR requirement:
Windows(DX12), macOS(Metal), Linux(todo)

[WhoCares]

v2.1.2

HDR rendering for Linux supported.
Requires: Vulkan + Wayland. Plasma KDE 6.x or Gnome 50+ preferred.

[blue_devil]

Originally Posted by WhoCares

v2.1.2

HDR rendering for Linux supported.
Requires: Vulkan + Wayland. Plasma KDE 6.x or Gnome 50+ preferred.

What about XFCE?

[WhoCares]

X11 is a legacy display protocol with no standardized native HDR support. While there are some experimental patches, only Wayland offers widely adopted, production-ready HDR capabilities.

As of Xfce 4.20.1 (released April 26, 2026), the desktop environment maintains full X11 compatibility and offers experimental Wayland session support. Note that xfwm4 has not been ported to Wayland; an external compositor such as Labwc or Wayfire is required.

Wayland sessions support HDR output when running on a graphics stack that implements the VK_EXT_swapchain_colorspace and VK_EXT_hdr_metadata Vulkan extensions. While these extensions are technically compatible with Vulkan 1.0, all production-ready HDR implementations in Linux require drivers that support at least Vulkan 1.2.

Verified working configurations:
AMD GPUs (GCN 3+): Mesa RADV 25.1+
Intel GPUs (Gen 9+): Mesa ANV 25.1+
NVIDIA GPUs (Maxwell+): NVIDIA proprietary driver 595+

Originally Posted by blue_devil

What about XFCE?

[wild]

two suggestions:
- add a "play in random order" option
- add a "Ken Burns effect" to the image transitions ( https://en.wikipedia.org/wiki/Ken_Burns_effect )

[WhoCares]

hello wild,

thanks for your advices!

Will add them in later versions.

BTW, random play will invalidate "image preloading", which is important for fast image navigation by order.

Originally Posted by wild

two suggestions:
- add a "play in random order" option
- add a "Ken Burns effect" to the image transitions ( https://en.wikipedia.org/wiki/Ken_Burns_effect )

[wild]

can't you:

• Build a list of all file paths.
• Shuffle the list once.
• Iterate sequentially through the shuffled list.
• When exhausted, reshuffle again (optional).

This guarantees:

• every image appears exactly once per cycle
• no duplicates before all images are shown
• O(n) setup cost
• O(1) per image retrieval afterward

here it is a VERY stupid C example:

#include "stdio.h"
#include "stdlib.h"
#include "time.h"

void shuffle(char *arr[], int n)
{
    for (int i = n - 1; i > 0; --i)
    {
        int j = rand() % (i + 1);

        char *tmp = arr[i];
        arr[i] = arr[j];
        arr[j] = tmp;
    }
}

int main(void)
{
    char *images[] = {
        "img1.jpg",
        "img2.jpg",
        "img3.jpg",
        "img4.jpg",
        "img5.jpg"
    };

    int n = sizeof(images) / sizeof(images[0]);

    srand((unsigned)time(NULL));

    shuffle(images, n);

    // show all images exactly once
    for (int i = 0; i < n; ++i)
    {
        printf("%s\n", images[i]);
    }

    return 0;
}

now I see that you are using RUST:

extern crate rand;
use rand::rng;
use rand::seq::SliceRandom;

fn main() {
    let mut images = vec![
        "img1.jpg",
        "img2.jpg",
        "img3.jpg",
        "img4.jpg",
        "img5.jpg",
    ];

    let mut r = rng();

    // shuffle once
    images.shuffle(&mut r);

    // show all images exactly once
    for img in images {
        println!("{}", img);
    }
}

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=bf21ee09177a42b6d9a1245f59fe1fc4

[WhoCares]

good idea to keep "image preloading" valid.

I have implemented random view with your approach.
https://github.com/z16166/SimpleImageViewer/releases/tag/v2.2.1

I will reconsider how to implement "Ken Burns effect".
It may be an image rendering effect, instead of a transition effect to switch to the next image.

Originally Posted by wild

can't you:

• Build a list of all file paths.
• Shuffle the list once.
• Iterate sequentially through the shuffled list.
• When exhausted, reshuffle again (optional).

[wild]

Originally Posted by WhoCares

I will reconsider how to implement "Ken Burns effect".
It may be an image rendering effect, instead of a transition effect to switch to the next image.

You are right: it is an image rendering effect, but please keep it in mind: it gives a new life to slide shows!