Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RapidRAW: A non-destructive and GPU-accelerated RAW image editor

github.com

Post reply on HN
Print view View original

11–20 of 127 posts

Re: RapidRAW: A non-destructive and GPU-accelerated RAW image editor

#11

Post by cybertimom »

polishdude20 wrote: post #7

Hey congrats on the app! This is just what I'm looking for :) Just installed it on my m1 mac and opened a folder of RAW files. The initial loading lagged my whole macbook. Couldn't even open the dock. Once the thumbnails all loaded it's better but not as buttery smooth as I would have hoped! Would love to know what other commercial apps do that make them not lag. Is it just that they're written natively?

Thanks for trying out RapidRAW and for the feedback. Currently I optimized the app to load small-medium sized folders (e.g. 1-300 images). Its expected that the app lags for folders with more images.

Its a high priority to optimize the loading speed of large folders and you can expect an improvement in the coming days.

Kind regards, Timon

Re: RapidRAW: A non-destructive and GPU-accelerated RAW image editor

#12

Post by cybertimom »

dylan604 wrote: post #3

Why the decision to store edits in sidecar instead of the app’s library? I’m sure there’s pros/cons that were considered, so curious how the pros won out.

Its pretty simple to explain: Imagine you have your images in a folder and you rename this folder, without RapidRAW knowing this. It would fail to associate the edits with the image. Lightroom does it the same way. Or imagine you‘re editing on your computer and want to move to your laptop to continue editing - the edits would only be saved on the computer, if it‘s only saved in the app library.

Re: RapidRAW: A non-destructive and GPU-accelerated RAW image editor

#13

Post by ethan_smith »

dylan604 wrote: post #3

Why the decision to store edits in sidecar instead of the app’s library? I’m sure there’s pros/cons that were considered, so curious how the pros won out.

Sidecar files (like XMP) are the industry standard for non-destructive RAW editing - they maintain file portability between different apps and preserve your original files. Library-based approaches offer better performance and organization but create vendor lock-in and complicate backups.

Re: RapidRAW: A non-destructive and GPU-accelerated RAW image editor

#14

Post by miladyincontrol »

Will def keep an eye on things. If theres one 'must have' feature I can request, luminosity masking? Its hard to go back to raw editors that dont have it. Its not the end all or be all to masking (ie color, saturation masking, etc) but is def one the most useful to have access to without having to bust open PS or similar.

Already having a workflow for AI based subject masking is def nice to see.

Re: RapidRAW: A non-destructive and GPU-accelerated RAW image editor

#15

Post by TheDong »

polishdude20 wrote: post #7

Hey congrats on the app! This is just what I'm looking for :) Just installed it on my m1 mac and opened a folder of RAW files. The initial loading lagged my whole macbook. Couldn't even open the dock. Once the thumbnails all loaded it's better but not as buttery smooth as I would have hoped! Would love to know what other commercial apps do that make them not lag. Is it just that they're written natively?

I mean, it's making 720px width jpg thumbnails using the CPU https://github.com/CyberTimon/RapidRAW/blob/fc21ede729b45d97...

And then it's sending these thumbnails back from rust to javascript as base64 encoded strings, not using a shared buffer: https://github.com/CyberTimon/RapidRAW/blob/fc21ede729b45d97...

This is the sorta stuff that native apps mostly don't do. They don't base64 an image just to send it to a different app (react) to base64 decode it (via a third app, webkit) via a slow ipc mechanism (tauri) from itself to itself, allocating 6x the chunks of memory along the way for one bit of data (the 6x are: raw data in rust, base64 data in rust, json encoded base64 in rust for tauri ipc, json encoded base64 in javascript, base64 in javascript, raw image data in webkit to finally view).

Re: RapidRAW: A non-destructive and GPU-accelerated RAW image editor

#16

Post by strogonoff »

The best raw image processing tool I know is called “RawTherapee”. It was developed by one or more absolute colour science geeks, it is CLI-scriptable, its companion RawPedia is a treasure trove of information (I learned many basics there, including how to create DCP profiles for calibration, dark frames, flat fields, etc.), and not to make a dig (fine, to make a bit of a dig) you can see the expertise starting with how it capitalizes “raw” in its name (which is, of course, not at all an acronym, though like with “WASM” it is a common mistake).

Beware though that it tends to not abstract away a lot of technicalities, if you dig deep enough you may encounter exotic terms like “illuminant”, “demosaicing method”, “green equilibration”, “CAM16”, “PU”, “nit” and so on, but I personally love it for that even while I am still learning what half of it all means.

I’d say the only major lacking feature of RT is support for HDR output, which hopefully will be coming by way of PNG v3 and Rec. 2100 support.

Re: RapidRAW: A non-destructive and GPU-accelerated RAW image editor

#17

Post by mikae1 »

strogonoff wrote: post #16

The best raw image processing tool I know is called “RawTherapee”. It was developed by one or more absolute colour science geeks, it is CLI-scriptable, its companion RawPedia is a treasure trove of information (I learned many basics there, including how to create DCP profiles for calibration, dark frames, flat fields, etc.), and not to make a dig (fine, to make a bit of a dig) you can see the expertise starting with…

Local adjustments are really difficult though, as it only supports the good ole "Nik u point" tech. For this reason only I use darktable instead.

Would really like to be able to use RawTherapee's dual-illuminant DCPs (not available in darktable).

Re: RapidRAW: A non-destructive and GPU-accelerated RAW image editor

#18

Post by appleaday1 »

strogonoff wrote: post #16

The best raw image processing tool I know is called “RawTherapee”. It was developed by one or more absolute colour science geeks, it is CLI-scriptable, its companion RawPedia is a treasure trove of information (I learned many basics there, including how to create DCP profiles for calibration, dark frames, flat fields, etc.), and not to make a dig (fine, to make a bit of a dig) you can see the expertise starting with…

I like this one its simple and easy to use

Re: RapidRAW: A non-destructive and GPU-accelerated RAW image editor

#19

Post by Springtime »

I'm glad there are an abundance of visual overviews in the readme. Too many readmes about GUI programs lack them (or they'll point to a site which still lacks a clear indication of how it behaves).

That said, they're all GIFs and each ~10-22MB. Making loading the readme larger than the program size itself. Embedding some video would be snappier.

Re: RapidRAW: A non-destructive and GPU-accelerated RAW image editor

#20

Post by strogonoff »

mikae1 wrote: post #17
strogonoff wrote: post #16

The best raw image processing tool I know is called “RawTherapee”. It was developed by one or more absolute colour science geeks, it is CLI-scriptable, its companion RawPedia is a treasure trove of information (I learned many basics there, including how to create DCP profiles for calibration, dark frames, flat fields, etc.), and not to make a dig (fine, to make a bit of a dig) you can see the expertise starting with…

Local adjustments are really difficult though, as it only supports the good ole "Nik u point" tech. For this reason only I use darktable instead. Would really like to be able to use RawTherapee's dual-illuminant DCPs (not available in darktable).

I can see that it would not work well for cases like painting over parts of the image, which Lightroom et al. allow with ease. If you try to be “holistic” in your raw treatment and like me at most do a graduated filter or mask by colour, RT works well enough (the latest versions improved it a lot, too).
Post reply on HN