[v3] New major release discussion thread

[Lymphatus]

TL;DR

I'm planning a major update for Caesium and need your honest feedback on what you like—and what you don't—about the current version to help shape the new one.

Overview

Caesium v2 brought significant improvements over v1, particularly in code quality and features. Since January 2022, the software has processed around 2.3 billion images, compressing roughly 4.6 petabytes down to about 1.3 petabytes. Despite these successes, the growing number of issues and feature requests indicates that a new major version is needed.

Background

I started Caesium in 2009, right after high school, using C++ and Qt, which were my go-to technologies at the time. Over the years, as I became a Full Stack Web Developer, I integrated new technologies—like Rust for the core library—to keep the project alive while professionally focusing on completely different languages and technologies. Although web-based UIs and Electron were popular choices, I stuck with Qt because of familiarity and its multiplatform capabilities.

Current Concerns

My personal concerns about Qt:

• Using C++ (which isn’t my strongest language) makes maintenance harder.
• Qt Widgets can look outdated, especially on macOS, and often lag behind in adopting modern OS features like Windows 11 Dark Mode.
• The auto-update system is clunky and relies on third-party tools (Sparkle/WinSparkle).
• The build and release process is cumbersome, requiring the full Qt framework and complex packaging.

Maintenance Challenges:

• Adding new features—such as an improved preview window—often demands extensive refactoring.

Looking Ahead

For the next major version, I want to retain Caesium’s core strengths (speed, efficiency, and user-friendly design) while addressing these pain points. My goals include:

• Enhanced UX/UI: Modern, appealing design and streamlined workflows for beginners.
• Seamless Auto Updates: A robust and easy-to-maintain update system.
• Simplified Build/Release Process: Automated CI/CD with support for major release channels (e.g., Chocolatey, Winget, Homebrew) and a focus on Linux releases.
• Better Testing: More comprehensive test coverage.
• Alignment with Modern Skills: Leveraging my strengths as a web developer (you see what's coming?).

My Proposal: Tauri

I'm considering switching to Tauri for the next version. This approach would let me write the heavy logic in Rust (using libcaesium) while designing the UI with modern web technologies, which I'm far more proficient with. Though Tauri uses a WebView—which might increase the app’s size, memory footprint, and require extra work for image format support (like TIFF)—I believe these challenges are manageable.

Your Feedback

I’d love to hear your thoughts on:

• What you like and dislike about the current version.
• The idea of moving to Tauri.
• Any alternative suggestions you might have.

Your honest feedback is greatly appreciated as I work toward a better Caesium.

[ru-bem]

What you like and dislike about the current version. Everything, but mostly: Compare the results with the original - Skip if output size is bigger than the original - Perform an action after successful compression.

The idea of moving to Tauri. I'm new to programming so I don't have much to say about this.

Any alternative suggestions you might have. AVIF Support (SVT-AV1-PSY) - JXL Support - Custom parameters

Also, thanks for keeping working on Caesium.

[qinlili23333]

It's excited to see the migration to Webview based solutions. I also love Webview based solutions for my personal projects, since it's easy to debug. But I have some concern about the performance of large lists in Webview. Many users like me may add thousands or even more items into list, but long list in Webview has a really poor performance based on my test. You may need virtual list to get acceptable performance while it brings difficult to accessibility tools such as screen reader.

You may check this project -- limitPNG, a similar image compression tool built on electron, which I used for years but finally drop due to UI performance issue.

[Lymphatus]

@qinlili23333 you are absolutely right about performance on large lists. Based on the stats I have, there's people adding even millions of images at once into Caesium. I tried the simple solution of showing them all in a table, but even on medium to high spec systems, it was buggy and UI was freezing.

My solution, for now, is to keep the full image list on the Rust backend - which has no problem handling it - while paginate the items in the UI. You don't have the full thousands of items list, you only see a chunk of it, but you can easily navigate with pagination and I'm planning on adding a search/filter feature.

I was also questioning myself: if I have thousands of elements in the list, do I really need to see them all at once? I think the search/filter plus sorting should be a sufficient enough solution.

[7eventech77]

What you like and dislike about the current version. Likes

• Dark Mode
• Nice UI
• Ability to still use effectively on small screens such as Windows Tablets or in side by side windows on one monitor
• Ability to convert format and resize in one operation
• Ability to use the program offline and not upload to a web server
• Open source & Free Dislikes
• Lack of wide codec support ie. HEIC, AVIF, JPGXL

The idea of moving to Tauri. Honestly I'm not a programmer so I wouldn't be able to provide any input on this one.

Any alternative suggestions you might have.

• Additional codecs - AVIF & JPEGXL encode and decode support would be super nice to have. I don't want to have to upload personal photos to a web server who does who knows what with them to convert formats. Being able to convert to HEIC would also be nice as well but I'm not dead set on it due to the format being sort of awful outside of compression (licensing, support, etc.). What I really want is for Caesium to READ HEIC images so I can convert them out of the almost useless format to JPG or WEBP. I have to use a separate program just to convert from HEIC/HEIF to JPG so websites and programs can read them and it is a pain. If you don't want to enable encoding to HEIC, PLEASE enable read capability for Caesium to open them so we can convert away from that format.
• Android/IOS app? Not sure how feasible this would be but some people might find it useful if Tauri supports it.

Thank you! Appreciate your work!

[Lymphatus]

@7eventech77 HEIC is a nightmare, to be honest. I don't wanna get into too much details here, but it's a proprietary codec and has a few licensing quirks attached to that. AVIF or JPEG XL are way easier and I'm starting exploring those formats.

Android/iOS support: Tauri, technically, allows to develop for mobile too. I would not go this way tho, because I don't wanna have too much concerns about an UX/UI that works both for desktop and phones. If I'll ever find the time to develop a mobile app it would probably be a React Native/Native Script kind of app (going Kotlin/Swift is out of reach of my current skills). The main problem here is that I'm a solo developer for this project, and maintaining a library, a CLI, a web app, and a desktop app in my free time can be exhausting at times. Adding a mobile app might be too much to handle 😁

[7eventech77]

@7eventech77 HEIC is a nightmare, to be honest. I don't wanna get into too much details here, but it's a proprietary codec and has a few licensing quirks attached to that. AVIF or JPEG XL are way easier and I'm starting exploring those formats.

Android/iOS support: Tauri, technically, allows to develop for mobile too. I would not go this way tho, because I don't wanna have too much concerns about an UX/UI that works both for desktop and phones. If I'll ever find the time to develop a mobile app it would probably be a React Native/Native Script kind of app (going Kotlin/Swift is out of reach of my current skills). The main problem here is that I'm a solo developer for this project, and maintaining a library, a CLI, a web app, and a desktop app in my free time can be exhausting at times. Adding a mobile app might be too much to handle 😁

I sort of figured that you might say that was the case with HEIC. Does this nightmare still apply even if you use it to merely open an image to be converted to another format versus implementing an encoder to convert images to HEIC? I apologize if I am ignorant, I haven't read up on all the details of the nightmare of the codec haha.

As for the mobile app, no worries. I figured it would be a little too much right now. Thank you so much for responding though. I am excited for v3.

Also, will version 3 still support Windows 10 22H2 or will the minimum version be Windows 11? I know a lot still use 10 including myself due to the disaster that is 11.

[bwoodruff]

I'd love to not have to install Rosetta to use it on Apple Silicon Macs. Is an arm64 macOS version on the table?

[garywill]

I've some ideas about the preview comparison UI.

1. Placing new (compressed) and old (original) images side by side for comparison is bad. The approach used by Google Squoosh, where the old and new images are overlaid and a draggable divider is provided, is also not great.

   I believe a better preview UI design would be:

   1. Overlapping old and new images with devider there, allowing user to start divider oscillating (equivalently switching between images). That can maximize the visual area and save user mouse operation.

   2. Not limiting the comparison to just 2 images, but allowing the comparison of multiple images of different compressing parameters

   Above two features have already been implemented in a web project by me (still quite rudimentary). You’re welcome to try it out https://garywill.github.io/ivacomp/

   Side note: In my web project, I wanted to extend media comparison beyond just images, so I also added a video comparison feature to preview the video and audio before and after compression. However, it seems challenging to achieve precise synchronization of two videos when playing them simultaneously on the web.

2. I previously filed the FR for SSIM, in #262. Personally I expect to see that in future Caesium

[Lymphatus]

@7eventech77 not sure, I did not go into too much legalese details, but also the tech side is a bit a nightmare. We can dig a bit further on this in the future maybe. Windows 10 is still very much on the table. I even think I could support Windows 7 again with v3!

@bwoodruff main reason Caesium is not built for ARM on Mac is that my Apple machine is an old Intel one. I'm planning on upgrading to an Apple Silicon one in the future, but even if I won't, I should be able to setup a CI to build for ARM anyway, very much like I do with the cli tool. So, yes, no Rosetta anymore.

@garywill

1. Totally agree. Side-by-side was good enough for 2010, not for 2025. Having just one panel to preview the image also saves a ton of space on the UI.

   1. I'm testing this approach. I still don't know if it will be like Squoosh with a draggable handle to progressively switch between images or just a toggle, I'm exploring some solutions right now. I'll also put some better zoom controls, a button to put the image on 100% zoom or fit the window.
   2. Interesting. I don't know how much is appealing for a casual user that does not really want to min-max the quality/compression ratio, but I can see its uses for some users.

2. As I said in the issue, it could be a nice addition. I don't see it as a priority because there's much to do with this v3, but once the big stuff is implemented I will re evaluate it. One difficulty I already see right now is to make sure the SSIM can work with every image format that Caesium supports, which might not be trivial.

[7eventech77]

@Lymphatus That is great news! I wonder if Windows on ARM is also something you could support if you can support Apple ARM silicon

[Lymphatus]

@7eventech77 I Guess yes, but never actually tested it, so can't really confirm it right now.

[mlloewen]

While I am not a big fan of webview apps(I actively avoid electron apps when I can find any alternates). tauri is probably the best option if you must use webview. Please look to other UI as the memory bloat/data sharing of chromium(I don't trust).

[bovirus]

@Lymphatus

Could you please consider not integrate language file in .xe file but elave external in a program subfolder? Or could you enable the option to use an external .ts/.qm language file to test translation revision?

[Lymphatus]

@mlloewen I understand your concerns, I'm pretty much on the same boat. I evaluated a few other alternatives (Qt + QML, AvaloniaUI, Flutter, Electron, Iced...), but I think none of them is better - at least for me - than Tauri. I put a lot of effort in performance optimization to match the current Qt level.

@bovirus not sure how the translations will be managed in the future, but I'll probably ditch the whole ts/qm files

[bovirus]

@Lymphatus

Why not .ts/.qm? For me .ts file is an efficient way to maintain translations. My suggestion is not include language files in main.exe and leave .ts/.qm file external in 'translation' folder. In this way you can help the translator to revise and test language file.

Thanks. KR.

[Lymphatus]

@bovirus I used ts/qm because of Qt, but since the new version will be on a different tech stack, I'm not sure how I'll actually manage all translations at the moment.

By the way, this is a very very alpha screenshot of what the next version could look like. Keep in mind this is nothing more than a prototype, but I just wanted to let you see what's in the work.

[stamminator]

@Lymphatus Even in alpha, it already looks more clean and modern than v2. Nice job.

One bit of subjective feedback: I'm generally not a fan of using unlabeled icons for menu items unless there's no room for them. Taking turns holding my cursor above buttons so I can see their tooltips always makes me feel like I'm wasting time. It's fine in some cases (the settings icon, the -/+ zoom icons, etc.), and other times it's unavoidable because of the sheer number of options (e.g. GIMP, Inkscape), but in general, I think icons + labels are better.

[Lymphatus]

@stamminator totally agree with you, I will definitely add the option to show/hide toolbar button labels as it's in the current version.

[qinlili23333]

It's nice to see the prototype. Just a friendly reminder, to keep compatibility with touchscreen and other non-mouse input device, ensure pointer events are used instead of mouse events, especially for those slidebars. https://developer.mozilla.org/en-US/docs/Web/API/Pointer_events I had to spent some time to fix my own project just for these things a few years ago.

[7eventech77]

@Lymphatus Definitely in favor of the new UI of the very alpha build. Looks great. Also agreed with the suggestions made above. Can't think of anything else right now to add outside of maybe allowing the toolbar (File, Edit, View etc.) to show/hide . Great work and thank you!

[bovirus]

@Lymphatus Thanks for new UI and new program layout. I hope that you can continue to ude .ts/.qm language file system (very useful for translators).

[stamminator]

@stamminator totally agree with you, I will definitely add the option to show/hide toolbar button labels as it's in the current version.

I actually didn't realize this was an option until just now. Might I suggest "Icons and Text" mode be the default in v3?

[JeckPeppinger]

have you considered an option to Normalize / Autoimprove images? This is a standard feature in xnview for example, and would be a valuable tool for batch image compression.

[JeckPeppinger]

the build process for linux is really tedious. qt update with tons of files that cant be deleted after build, compiling the software is not an issue when its stable - which is not the case for my ubuntu install. its always a guess whether compiling will work.

[Lymphatus]

Linux should be supported out of the box with Tauri with AppImage releases, which should solve a lot of compilation problems.

[dhry]

JPEG-LI support will be an excellent addition. XNView-MP already supports it for recompression. https://opensource.googleblog.com/2024/04/introducing-jpegli-new-jpeg-coding-library.html

[WPNL72]

I like the app but the only concern I have is that the anonymous usage report contains the output paths on our computers, this does not "feel right" with me.

[cenda]

@Lymphatus any estimation about first public beta of v3? thx ;)

[Lymphatus]

@WPNL72 agree with your concerns. While you can disable the reports, I think it can be safely removed.

@cenda not yet. The development is at a good stage and most of the features are ported to the new version. I might release an alpha first - with some missing features - and start collecting feedbacks.

[cenda]

@Lymphatus Great news! Can you confirm that v3 would support apple silicon chips? Or is it still in "feature request" stage?