RapidRAW on mobile in the future?

[JonasPetri]

Hey, I was just wondering whether you have thought about making a mobile version for Android and/or iOS in the future. Since it’s built with Tauri I feel like it shouldn’t be too difficult to port it to mobile. And since the interface is quite simple and streamlined I don’t think any major UI changes would even be necessary to adapt it to touchscreens. I understand it’s not at all a priority at this point, but it would be really cool if RapidRAW could be available on mobile too in the future.

[CyberTimon]

That's a good idea! I'll look into the possibility of creating Android tablet builds - it's definitely something that could work well given the current UI. As for iOS, I don't have much experience with Apple development and don’t have a way to test it properly, so I wouldn’t expect iPad builds any time soon. I’d be happy to review any pull requests if someone wants to look at it!

[nicks-crumpets]

This is something I'm really looking forward to, I'm just starting to learn mobile development so I'll see if making a prototype is doable sometime soon!

[Duecki1]

Hi, i've tried porting RapidRaw to Android and it works via Tauri V2. The problem I have now, its crashing as soon as any slider is adjusted.

In the meantime, I've created a Kotlin Port using the Raw processing. Not sure if thats really the right way to do this, but I would love to edit pics not only on tablets, but also on Android Phones. The UI right now is not very efficient, but it works mostly.

https://github.com/Duecki1/IRIDIS

[tobiasBora]

Just wanted to say that the kotlin port works great, especially now that the RAM issue is solved (just waiting for a release see Duecki1/IRIDIS#2)! Keep up the great work!

[Duecki1]

RapidRaw on Android via TauriV2:

Screen_Recording_20251220_155150_RapidRAW.mp4

Kotlin App using RapidRaw's Rust processing:

Screen_Recording_20251220_155228_IRIDIS.mp4

[nicks-crumpets]

Awesome! I've just tested it and it runs pretty well on my Pixel 6a (Graphene OS)
Would be interesting to see if the preview could stay full res while edits are being made, currently it decreases the resolution and the edit almost increaces and decreases in 'chunks' as the slider is moved, and the slider is a little laggy too.

Still besides that this is incredible and I'm really happy you've done this, android RapidRaw looks closer than I expected!

[Duecki1]

The purpose of rendering the image in a lower quality at first, is to make the slider more responsive on lower end devices.

On my s25u rendering at a higher res is still pretty responsive:

Screen_Recording_20251221_174802_IRIDIS.mp4

But on my pixel doesn't like rendering at such resolution:

screen-20251221-174323-1766335390540.3.mp4

I will add an option for disabling or enabling low res rendering tho.

[Duecki1]

@nicks-crumpets and thanks for trying it out and giving me some feedback :)

The only issue I see it the highlight recovery, but I think thats an Issue in RapidRaw desktop too.

[Duecki1]

Awesome! I've just tested it and it runs pretty well on my Pixel 6a (Graphene OS)
Would be interesting to see if the preview could stay full res while edits are being made, currently it decreases the resolution and the edit almost increaces and decreases in 'chunks' as the slider is moved, and the slider is a little laggy too.

Still besides that this is incredible and I'm really happy you've done this, android RapidRaw looks closer than I expected!

In the newest release you will find a settings page to disable or enable low quality preview.

Commit: Duecki1/IRIDIS@25c8a16

[CyberTimon]

@Duecki1

Wow this is great progress! You can be proud of yourself. I really like the super fast preview mode. Do you think something like this is also possible for RapidRAW? Also, have you tried to experiment a bit with the wgpu backends and settings and have you been able to take a look at the log file? Maybe this tells a bit more about the error.

[Duecki1]

@CyberTimon

Thanks! I already tried implementing a fast preview mode by rendering at a lower resolution on PC, but it didn’t really improve loading times, at least not with my current implementation. I’ll take another look at it and double-check whether it’s actually doing anything or if I messed something up.

The Android port is behaving very strangely. I suspect it might be related to file read and write handling on Android.

On first launch, the app is supposed to ask the user to select a folder, but I couldn’t get the Android file picker to work properly. As a temporary workaround, the app now automatically creates a folder when it detects that it’s running on Android. If you put RAW files into that folder, the app detects them correctly. Opening a RAW file for editing also works, and all sliders respond but don't do anything.

However, the adjustments don’t seem to be saved correctly. Sometimes, after reopening the app, the RAW file suddenly has adjustments applied from a previous session, but the sliders are still at zero. Other times, changing sliders appears to do nothing at all.

It’s really hard to describe. You change a value, nothing happens, and then at some random point later the image updates, but the UI state doesn’t match the actual image anymore.

I haven’t checked the log files yet. I’m not sure what the best way to do that on Android is, and I also couldn’t find any obvious errors in Android Studio’s Logcat so far.

In my opinion, TauriV2 for Android is missing a lot of Documentation.

[nicks-crumpets]

Hi, i've tried porting RapidRaw to Android and it works via Tauri V2. The problem I have now, its crashing as soon as any slider is adjusted.

In the meantime, I've created a Kotlin Port using the Raw processing. Not sure if thats really the right way to do this, but I would love to edit pics not only on tablets, but also on Android Phones. The UI right now is not very efficient, but it works mostly.

https://github.com/Duecki1/IRIDIS

Looks awesome! Looking forward to checking this when I can figure out why my building of the app keeps failing (Jetbrains toolbox gave me the wrong android studio version, whelp)

[Duecki1]

If you want to try the app, you can use the apk: https://github.com/Duecki1/IRIDIS/releases/tag/0.1.1

[nicks-crumpets]

Thanks! Will do that, I'll assume I missed that on the GH page, whoops!

[Duecki1]

Thanks! Will do that, I'll assume I missed that on the GH page, whoops!

It's pretty hidden, I think because it's a pre-release.

Please let me know if it works and how you like it. (The UI right now is horrible, I know xD)

[Duecki1]

@nicks-crumpets Subject mask could take up to 5mins for the first time, it will first have to download the model. The small bar below images in the gallery view is the progress bar of the automatic tagging model.

And I haven't yet tested the performance on lower end devices. The app works fast enough on my s25u, a pixel 7pro and a pixel tab emulator.

[nicks-crumpets]

Gotcha, gonna try on an emulator for now and when I get back home I'll put it on my Pixel 6a (running Graphene OS) and see how it runs. I'll give the subject mast time too :)

[Duecki1]

@CyberTimon Hi, i wanted to ask if you are planning to add Immich support to RapidRaw? And if so, do you also have syncing in mind?

I was considering implementing it via a pull request, but I’m not sure what exact feature set to implement or what the workflow should look like.

To test some thing, I already integrated Immich into the Android app:

You can connect to an Immich server and download RAW files for local editing.

I also prototyped a “sync edits” feature, but it’s a bit sketchy right now, it stores the adjustment data as a Base64 string in the image description, since Immich (as far as I can tell) doesn’t support attaching arbitrary sidecar data, only media files. Do you have a better idea on how to sync edits?

if possible I would even try to make them compatible, not sure if you want to tho.

IRIDIS

[CyberTimon]

@Duecki1 That sounds fantastic! To answer your question: Yes, I would like to integrate Immich into RapidRAW in the future.

The main reason it hasn't been a priority yet is simply that I have no experience with Immich and currently have no idea how it works under the hood (API, asset handling, etc.). However, I’m planning to set up a demo Immich instance soon specifically to change that, so I can at least test some stuff and see what is possible.

As you have already integrated Immich into your mobile port, do you have any tips or info for me?

[Duecki1]

@CyberTimon That sounds awesome. I think Immich would be a great fit for RapidRAW, because it could show up like an extra drive (cloud) in the folder explorer on the left. The user could browse their library, tap any RAW file, and RapidRAW would download it on demand for editing.

If you want syncing later, that’s possible, but it’s a bit tricky because Immich mainly supports media and doesn’t really offer a clean place to store arbitrary edit data. The only reliable spot I found was the image description field. Right now I store edits there as separate entries per editing session so changes can be reverted, but it’s not ideal because the description grows quickly. My plan is to optimize this so it keeps only one edit state per device instead of appending every session.

Integration itself worked pretty smoothly, entering the Immich server address and using an API key was straightforward and reliable, just not very user-friendly. So I added login via acc, and that’s where I ran into issues. The in-app login wasn’t supported by my host (I’m using PixelUnion until I buy my own server). I switched to logging in via the browser, which is supported, but then I started hitting deep-link problems, the website wouldn’t open my app after login, and sometimes it would open the official Immich app instead of mine if it was installed. I haven’t dug into how the desktop OAuth flow handles this yet.

Other than that, I didn’t run into major problems, and the API documentation is genuinely good, which makes experimentation and debugging much easier.

https://api.immich.app/introduction

[Duecki1]

if you want, i can try to integrate it and do a pull request.