New Image Viewer: avis-imgv

Nice :smiley: Good to know

Excuse the necro but just want to let everyone know that the crate has been published to crates.io. So if you have rust installed on your machine, you simply need to run ‘cargo install avis-imgv’ to install it. (It will only be available through the command line if installed through that method).

3 Likes

Cool! Here’s the link (just for quick reference):

https://crates.io/crates/avis-imgv

1 Like

Unfortunately, Ubuntu 23.10 comes with rustc 1.71.1, and 1.72 is required.

1 Like

Thank you!

One more necro:

I’ve added a few more features and polished/optimized it a little more. I still use it as my main image viewer. The full change log is on github :slight_smile:

A cool feature is that now you can latch “Maximize” so when scrolling through a collection of images with different aspect ratios they will always be as big as they can be (without cropping) on the screen.

Now, after importing your images, you can filter them using exif tags:

It’s very rudimentary queries but it runs extremely fast(tested with 125k images) as I’m using the new JSONB column type in sqlite. Import is also not so bad as it only took me around 15-20 minutes for 125k images on a HDD. Disk space usage is minimal, as of right now my database is under 600MB.

I will keep polishing it in the next few months, the next features will be:

  • RAW support, making use of exiftool’s ability to extract the JPEG preview;
  • Simple star rating system. Coupled with finding duplicates and automatically rating them as well;
  • GUI for configuration;
  • Feedback for user commands (success, error, etc);
  • Improve margins/font sizes to make the UI feel less claustrophobic;
  • Would like to have an app icon, something with a bird;
  • Deploy as flatpak;
  • Test on windows and maybe build an installer. Can’t do it on MacOS as I don’t have access to one.

After this I believe that I will only be doing bug fixes and consider the project done.

5 Likes


Another necro:

Development has slowed down due to lack of motivation but lately I have been doing some recreational programming to add some more features.

  • RAW file support by extracting the thumbnail with exiftool;
  • Display images side by side;
  • Added a slideshow functionality;
  • Architectural changes which are not yet complete but improve the behind the scenes quite a bit. I now have two image stores, one for full images and other for thumbnails. These work more or less like texture stores/managers in game engines. This was necessary to prevent deadlocks when writing to the GPU and will hopefully allow 16bit texture support in the future since I am now loading textures directly with wgpu. My idea is to bypass egui and compositor transformations. Color management is already implemented for input and output profiles since the start of the project, but I am not sure yet what is happening with the compositor, need to test this more;
  • Added an AI disclaimer in the README. For me this project is also a good way to hone my skills and do some recreational programming. To achieve this I am banning AI use in the project and all contributions with AI will be automatically rejected;
  • Will be moving to Forgejo in the near future.
5 Likes

Hey, cool! :raised_hands:

This is welcome! But depending on the camera model, the embedded bitmap thumbnails are often too small to judge sharpness and IQ.

I know it’s not written in rust, but have you seen QuickRawPicker? It was abandoned but was a really nice way of browsing raw files, culling and rating.

1 Like

They seem to use LibRaw. I am not against decoding and doing bare minimum de-mosaic on the raw files themselves. The project is in rust so I would probably use rawler

I’ll give it a test and see how it goes. There is a lot more work to get a viewable RAW file, I am not sure how much work rawler ends up doing.

Well, decoding seems to be pretty easy with rawler :smiley:

I am not sure of how worth going down this path is. Now I would assume that I need to apply a few operations to get a usable image out of this, can any dev point me to a resource where I can learn what needs to be done?

1 Like

Another possibility would be to have the option of calling an external program to render the raw file.

1 Like

This might be a good idea. Do you have any suggestions?



I am playing around with this for fun and also to learn a bit about what happens to the raw data to get a usable image.

I feel like I am close to getting a useful image, but when I apply the color matrices, there is a strange cast in the image. If I skip this step and go straight to applying an srgb gamma curve, it looks “normal” but I am aware that this is not correct.

This is what I’m doing:

  1. Apply black and white point scaling
  2. Apply WB coefficients
  3. Very rude demosaic where I just fetch the nearest pixel of that type(r, g or b) I am aware that this can lead to unbalanced behavior
  4. Apply matrix to convert camera rgb to xyz
  5. Apply matrix to convert xyz to linear srgb
  6. Apply simple Reinhard tone mapping
  7. Apply srgb gamma curve

I wonder if this is because of the shoddy demosaicing which is amplified by the matrix conversions?


Some success. But testing PlayRaw images reveals some problems

So… from some quick tests, Fuji uses column major and other brands are using row major for the matrices?

row major:

column major:

Still missing something though.

1 Like

I just found out rawler provides a built in developer… Could’ve saved me a few hours, except the decoder does not seem to work on X-Trans, I’ll report the bug and implement the built in decoder for the rest :slight_smile:

EDIT: It’s not a bug, demosaic just isn’t implemented yet for x-trans, which is fair.

1 Like