Exetools

Exetools (https://forum.exetools.com/index.php)
-   Source Code (https://forum.exetools.com/forumdisplay.php?f=46)
-   -   Simple Image Viewer (https://forum.exetools.com/showthread.php?t=21549)

WhoCares 04-02-2026 14:59
Simple Image Viewer
 
Manual image view + Auto image slideshow + Background music playback.
Powered by Rust + egui.
Windows/macOS/Linux

https://github.com/z16166/SimpleImageViewer

wx69wx2023 04-06-2026 21:33
1 Attachment(s)
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 04-06-2026 22:25
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.

Quote:
Originally Posted by wx69wx2023 (Post 134990)
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 04-08-2026 23:10
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 05-07-2026 13:57
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 05-23-2026 14:31
v2.1.2

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

blue_devil 05-23-2026 18:48
Quote:
Originally Posted by WhoCares (Post 135305)
v2.1.2

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

WhoCares 05-23-2026 20:47
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+

Quote:
Originally Posted by blue_devil (Post 135307)
What about XFCE?

wild 05-26-2026 11:17
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 05-26-2026 14:28
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.

Quote:
Originally Posted by wild (Post 135335)
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 05-27-2026 11:54
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:
Code:
#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:
Code:
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 05-27-2026 20:35
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.


Quote:
Originally Posted by wild (Post 135343)
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 05-28-2026 20:33
Quote:
Originally Posted by WhoCares (Post 135349)
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!


All times are GMT +8. The time now is 18:40.

Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2026, vBulletin Solutions, Inc.
Always Your Best Friend: Aaron, JMI, ahmadmansoor, ZeNiX