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.
I've been getting into photography lately too and running into the same question. There's no way I'm getting an adobe subscription. But I'm not sure what tools do I want to pick up instead. Apple Photos has gotten me pretty far, but I'm hitting the limits of what it can do. And my photo library is getting pretty big now - big enough that I want some software to manage where my photos live as well.
Played with Nitro this morning and compared my edits to those that came out of Lightroom and my camper manufacture’s RAW software and am very happy with the results. It has a user friendly interface, which I prefer to Lightroom’s, and I love that it’s a one time purchase. Thanks for the recommendation
Firstly it's a matter of reliably storing image files. I just make a new folder in the file system — each-time I transfer image files from camera to computer — named as the transfer-date YYYYMMDD. I wrote a 10-line script to give those image files unique-sequence-names YYYYMMDD-00N.ext.
So when I mistakenly copy into the wrong folder, it's obvious which image files don't belong. So I don't need to delay while I think of the best descriptive folder name. So I don't need to sort yesterdays photos into a different folder than todays photos.
Secondly it's a matter of deleting image files. I take a look with some viewer app and use the file system to delete whatever doesn't seem worth any more attention.
Thirdly whatever trial photo software is available is probably good enough to start learning.
Pixelmator pro is nice on the Mac, and it's a one time purchase, not even expensive. And CameraBag was not bad last time I tried it, also a one time purchase.
IME GUI is mainly important when you craft a new profile. In many workflows, you don’t do it very often. I create a profile once and then apply it to hundreds of frames without launching the GUI at all or mostly using it just to preview how the profile works with a particular frame and make a couple of minor tweaks.
I used RawTherapee a ton, but changed to Lightroom because the denoising is so much better. (I’m sure a more expensive camera would also help here, but I have what I have.) Now that I’m used to Lightroom it will be hard to switch back.
Yeah, LR's denoising is chef's kiss. It's much better than what Canon's own raw processor can do, for example.
Another thing I noticed with RawTherapee after LR was the sloooowness. Lightroom has been super optimized to show all edits (or their preview versions anyway) in real time.
Because those open-source editors are made by coders, not photographers.
Those tools you really need for properly edit raws are hidden in blated features (multiple demosaic algorithms) or completely missing (AI masking). And UI is not user friendly.
They are made by and for photographers. This software is designed for many use cases, not just creative photography - hence multiple demosaicing algorithms. AI masking is missing exactly because it's made by photographers - they don't have the required expertise. UI is not intuitive because a) it's designed by photographers' committee, not UI designers, and b) you are familiar with a completely different workflow.
Most photographers don't know how develop software at all.
Please explain why photographers need 20 differnet sharpening methods, 5 demosaicing algorithms, many colour corrections that are almost useles if AI masking is not present?
Coders often lost in all kind of geeky features that missing actual usability by targeted audience. Bloated software is not what I would expect from alternative to commercially used proprietary software.
Because it's not necessarily about creative/artistic photography, it's also for things like e.g. microscopy or negative or scan processing, and it's not an alternative to Lightroom which does "magic" unacceptable in many technical use cases.
You can ignore features that aren't made for you, and actually I think they're mostly hidden by default in DT (make a preset if you don't like the default tool selection). All these features were added because somebody needed them at some point, the DT/RT/ART communities are chaotic and lack vision but they're actually using their stuff.
>Coders
As I said, this is not software made by coders for coders. This is exactly how the software made by photographers would look if they lacked organization, focus, and UX skills. If it was made by coders (and UI designers), it would probably have looked like Lightroom and had AI selection.
Another terrible design in darktable is default settings. I have no problem with options, but then you need carefully choose defaults that are selected questionable here - pure exhibitionism right after opening software.
I don't agree with your statement about developing by photographers. If so, there is higher probability that they would focus on UI with more aesthetic care than coders would do.
Lack of AI masking is too expensive to use by professionals. You simply cannot afford to mask manually bunch of images. Wider adoption among photographers is simply impossible.
I mostly prefer RawTherapee's processing, with one exception: Darktable's stupidly good "filmic" emulation can beautifully recover overexposed raws that I thought were trash. It manages to make it easy to shift the entire scene one or two stops darker with just a few clicks (yes, there is data up there in raws).
I have not found an equivalent mechanism in RawTherapee. Does anyone know if it has an equivalent tool?
Parent was not talking about highlight reconstruction.
DT has a highlight reconstruction module too but RTs was superior every time I tried.
They're talking about the Filmic module which is a fancy exposure adjustment curve.
I ported it to Rust for use in our internal 2D compositing renderer (not open, unfortunately).
That's when I got to appreciate the work done there, really.
The gainforge crate has another port, although not with all parameters of the original algorithm, AFAIR.
The algorithm is explained in a blog post by the author of the module. [1]
Who is btw. the same guy that got fed up with DT dev and forked it to Ansel.
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).
One way could be exporting lossless 16-bit TIFF or PNG from RT, in some wide colour space and without sharpening, and then doing relighting + final processing steps in another tool… However, if you want to apply a CLUT after relighting then yeah, tricky.
It would be great if RT supported something along the lines of “take the entire canvas after initial raw processing but before CLUT and final touches and put it into a temporary file; allow me to do something with it in any other tool; then load it back and apply the rest of the steps on top of that”, but that might require it to store that edited canvas somewhere in addition to .pp3 file.
Well, it’s not a roundtrip if you just feed the output to another tool. My processing script typically pushes RT-prepared PNG to something like ffmpeg which may do resizing and more, depending on the end format.
RawTherapee is great in most ways, except that all of the curves for adjusting anything have absolutely catastrophically bad handling. It's so amazing having access to the Lab colour adjustments but the sliders are abysmal, impossible to make any kind of precise adjustments, impossible to reset an individual slider/point back to it's default placement, impossible to undo the last action without resetting the entire widget to its default state. It's unusable, and I'm convinced that the popularity of it would skyrocket if they'd finally just sit down and address that it's miserable to use. I would drop lightroom in a heartbeat if they made them even a little bit better.
I know it's a different space, but as a counterexample, FabFilter makes audio plugins that are the gold standard for that kind of interface and it isn't even close. Anybody making an interface for interacting with points on a curve should sit down with the free demo of FabFilters Pro-Q3 for just a few minutes to experience what's actually possible and how it should feel.
> 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).
Language pedantry has nothing to to with photographic image processing expertise and if anything this would be a sign that the developers care more about being "right" than what users want.
Those are certainly not mutually exclusive! The point of shooting raw is not to painstakingly tweak super-technical details, it’s to get processing latitude to make photos the way you want. Often that involves simple adjustment of shadows, highlights, saturation and so on, applied to a large number of photos in bulk.
The priorities are mutually exclusive: delegating scene data conversion to in-camera engine grants you the most simplicity and ease of use at the expense of control; the territory of technical details grants you the most ability to make the photos looks the way you want at the expense of simplicity. You dial one up, you dial the other down.
For example, your choice of demosaicing method can make a tangible difference in finer details: some methods would make them less noisy (better for some styles), others would better preserve finer details (better for other styles). Abstracting it behind one “more detail—less detail” slider isn’t going to work because “detail” can mean a multitude of things, of which sometimes you want one and not the other, and inventing new sliders with user-friendly but inscrutable labels a la “brilliance”, “texture”, and so on, can only get you so far.
There are shades between simplicity vs. control, of course, and so I am curious to know the answer from the horse’s mouth so to speak: to what end they choose to compromise simplicity.
It’s a case of diminishing returns. Shooting raw is a huge and obvious improvement if you want to post-process in almost any way. Conditional on that the workflow should be as smooth and simple as possible. Abstract controls like "clarity" are fine if the result of adjusting them is tangible and almost always does what you want. Giving the user lots of knobs that hardly have a visible effect (let alone a desired effect) is not an improvement.
Almost no professional photographer will care about the intricacies of the demosaicing algorithm, or the choice between a dozen different denoising modules, and Lightroom is entirely correct in not giving you a zillion knobs to adjust things that have no effect on image quality except in the rarest of cases. In 99% of cases the controls that matter are:
* Basic exposure/shadows/contrast etc
* Curves/levels for more control if needed
* White balance
* Cropping, obviously
* Cloning/healing brush
* Simple knobs for sharpening and NR
* Level/perspective adjustment
* Lens aberration correction (most of the time no manual input needed if the lens is in the batabase)
> Shooting raw is a huhe and obvious improvement if you want to post-process in almost any way.
See, you are saying “want to post-process”, which to me says that there is a different priority present rather than just “simplicity and ease of use”.
If the priority is “making the photos look the way you want them to look”, then we are in a territory where it is not as simple as “this tool is easy to use and therefore a better choice than that tool”.
You can want post-processing, but also don't want to spend 50 hours to learn a tool. Sometimes you just want "make it look close to the in camera jpeg, but let me adjust to exposure"
It’s not binary is the point and the whole reason I asked the original commenter why put premium into simplicity and ease and then immediately violate that by shooting raw.
When is the priority not “making the photos look the way you want them to look” ?
When you say “simplicity and ease of use” I think that includes taking the photos, and if I can defer some decisions that might make the overall process simpler.
I'm not the person you're responding to, but in my hobby experience it's sometimes the difference between a photo being fine or even great, and being completely unusable.
If the white balance is set wrong in-camera, then the JPG just came out all blue. It's effectively a black and white photo (albeit in shades of blue), and there's nothing to be done about it. Shot in RAW, the photo can be made color again, extremely easily and quickly.
In fact it gets worse, not better, if you on the day try to adjust the white balance, as you go from outdoors to indoors. Not to mention if you change from flash and back. Auto is safer, but when it's wrong, the photo is unusable, and the moment is gone.
But my DSLR is now over a decade old. Maybe "auto" has gotten much better?
So yeah, for me the main thing is to be able to post facto adjust white balance, which JPG does not support. (if you've done it with both JPG and RAW, you know what I mean when I say "does not support")
Right, I suppose shooting raw is good because you need to think less about your settings at shooting time.
I will say that “auto” is pretty decent on the phones in most common lighting scenarios like sunlight/shade/outdoor/tungsten/fluorescent—white point is an entirely subjective thing that cannot be reliably determined automatically, so in my experience you rarely get the correct rendition of, say, bright pink clouds at sunset, or a book with pink pages (the phone would think it must be the some weird lighting that should be corrected for, because obviously a book can only have nearly white pages, right?), etc.—but due to physical limitations of sensor size and inferior optics the phone is worse than even a decade-old APS-C DSLR in most regards overall.
I do think auto white balance is a little better these days. My old DSLR often had a strong magenta tint magenta in scenes with a lot of green (like forests). My new mirrorless camera from the same manufacturer no longer does that.
> The priorities are mutually exclusive: delegating scene data conversion to in-camera engine grants you the most simplicity and ease of use at the expense of control; the territory of technical details grants you the most ability to make the photos looks the way you want at the expense of simplicity.
The camera makes all those decisions even when shooting raw -- and there are stored in the raw file. So, by default, processing a raw file witout doing any tweaks will get you the jpeg you would have gotten.
My camera (Nikon) -- and I assume the others -- will even store both the RAW and the JPEG, so you don't even have to go through the automatic conversion step if you don't want to.
There's no inherent usability issue with shooting RAW. My experience has been that none of the open source tools can hold a candle to the proprietary ones.
RawTherapee I uninstalled almost immediately because it crashed a few times and the UI didn't seem to jive with what I wanted to do.
Despite DarkTable's horrific interface and hostile developers I keep it around because I can often beat it into submission (but what a chore that is). And that's the thing. Even if I were shooting JPEGs DT's interface would still be a problem.
I fought darktable for two years before feeling right at home. I had used Lightroom since it's inception. I'm happy now I invested the time. I much prefer the control darktable gives me now.
It's not about not "feeling right at home". I've detailed this in other comments but it's just that DT has an abysmal interface and that the devs insist that it needs to be complex. This sort of hostile attitude is part of what spawned Ansel.
I much prefer the control darktable gives me now.
This is a bit of a myth.
One of my complaints dealt with how unintuitive the sliders are. There's no additional control gained by making the UI widgets difficult to deal with.
Another dealt with trying to set color temperature. There are two places color temperature can be set and they'll both conflict with each other. The newer module is absurdly complex. It's great if you're writing a dissertation on color rendition but less great if you're trying to be productive.
Sure there's more control offered by having ten different demosaicing algorithms to choose from. Unfortunately I can't think of a time when I've needed or wanted that control. Maybe if I shot Fuji or Sigma. But I don't. And most folks don't.
Presets and history are a nightmare. Items in the history widget get aggregated so it's difficult/impossible to pick out individual steps. If you give labels to the actions in a preset (my terminology is off because I've not used DT much in a while)… sometimes they work. Sometimes they don't and things don't appear to pick up the label/group/whatever it's called. If memory serves I had to apply presets in one module to have them visible in the develop module.
The vestigial DAM stuff… ugh.
There's no obvious A/B split views.
Perhaps the most obnoxious thing is that DT shamelessly apes the Lightroom interface but in reality behaves almost nothing like Lightroom. There's a TON of complexity for little-if-any improvement in outcomes.
First, let me concur that Darktable is not great. I found it to be neither quite as simple as Lightroom, nor as powerful as RawTherapee, and severely lacking in documentation.
> Another dealt with trying to set color temperature. There are two places color temperature can be set and they'll both conflict with each other.
There are at least three colour temperature / white balance controls in RT; more if you count output colour space primaries, Lab space curve, etc. as ways of creative white balance control.
I’m not sure I see any particular conflict between them. They all do different things; some of them are more relevant if you want to achieve the most precise representation (e.g., you are digitizing analog prints or paintings), others are more relevant if you are going for a creative look of your own.
It’s probably best to consult RawPedia[0], but as far as I understand:
— One of them controls raw data interpretation, and affects how different tools work down the line (e.g., highlight recovery or targeting sky with wavelets). As far as I understand, you probably want to keep this one technically correct and as close as possible to the true neutral white/grey point; at this step you are helping the tool do the rest of its job and not trying to achieve a look. If you use a colour card, a DCP profile, etc., then you know exactly what to set White Balance controls to.
— There are a couple of controls under CAM model, which you may or may not be using depending on your profile. With scene illuminant you set… well, scene illuminant (the light you have in your scene), and viewing conditions allow you to shift colours to make it look right if you know your photo will be viewed in an environment with particular light.
— Then, of course, you have dozens of different ways of creatively controlling perceived white balance via different curves or CLUT; I think these are most handy if you are going for a look.
> I’m not sure I see any particular conflict between them.
I don't have DT under hand to check, but there are two controls which, if active at the same time, will produce a warning along the lines of "wb is already set in [the other control]".
The problems I listed were for Darktable. If you use the stock configuration and go into the "white balance" module you will get an error. If memory serves turning off the "white balance" module also leads to problems. Instead you're expected to go into the "color calibration" module. More powerful? Perhaps. Unnecessarily obtuse? Absolutely.
I tried Rawtherapee first as they actually sign their (macOS) app. Unfortunately it was too unstable to be useful.
I try to daily drive Linux but can't find a simple / nice to use RAW editor. I had high hopes for Darktable but I was astonished how bad the GUI is. When trying to delete photo, it deletes the photo under the pointer, not the photo I selected... WTF ?!? And the whole app feels so complicated... Then there's forks emerging and the dev forces are diluted in multiples applications and Adobe continues to milk its users because Open Source dev can't work together. Between Shotwell, Gthumb, Loupe, RT, DigiKam, and more... Imagine if all this efforts was done in one cohesive app ? Ok I stop dreaming.
If you seek a GUI for managing/cataloguing photos, my advice would be to look for that and not a raw image processing tool that incidentally happens to also handle cataloguing (inevitably in a half-baked way).
I have never seen Lightroom (or C1, for that matter) as compelling at all ever since I started using RawTherapee. Unlike, say, InDesign, which is legitimately a difficult to replace professional tool with incredible capabilities, Adobe’s raw image processing offering looks incredibly dumbed down.
Yes good point. But my needs are very limited. On macOS I use the Photo app to cull, make small adjustments, and crop. On Windows there is also a Photo app that allows such basic features. They both works with RAW and works fine with my NAS mount in smb to cull directly the files (though macOS is a pain for that, doesn't play well with files, need to import in lib).
On linux, the default Gnome image viewer is nice but you can't make adjustement and when deleting a file, the file is not remove from the NAS directory (need a manual refresh). With Gthumb it works for deleting files but the crop tool and the overall app is not as nice. Anyway I'll continue to look for my perfect app or for the default Gnome viewer to update its features (I think it is in active development)
my advice would be to look for that and not a raw image processing tool
that incidentally happens to also handle cataloguing (inevitably in a
half-baked way).
Eh. No? Lightroom is a pretty darn good DAM. Maybe digiKam is at least as good, but I wouldn't know as it crashed the first time I launched it. I want to use my tools, not debug them. DT's asset management is, to put it charitably, an after thought.
About the worst thing I can say about Lightroom is that it didn't reliably work with my iPhone. Otherwise it did everything I needed in terms of tagging, presets, and organizing the pictures on the file system.
Meanwhile darktable creates freaking sidecars for every picture while it relies on an SQLite database for tracking history just like Lightroom does.
I have never seen Lightroom (or C1, for that matter) as compelling at all ever since
I started using RawTherapee.
Conversely Darktable is the best advert I've seen for Lighgtroom.
Maybe Lightroom is okay for cataloguing, I cannot say because I have not used it this way extensively, but it is not up to par in terms of raw processing control in my view.
I have the same approach. I really like "easy to use, hard to master" tools in general.
If you look at CaptureOne you can see how easy it is to edit a raw image. Most of the time it looks like the camera jpeg without having to tune anything. But then you have the options to go in depth.
Sometimes I have a photo session where everything is to my liking, just a bit of exposure and crop. Other times I shoot in night clubs with no flash and I have multiple layers of masks for a single photo.
A UI with decent defaults goes a long way into making a complex app easy to use.
This tracks with my RawTherapee experience. I copy in base settings corresponding to the camera and the lens and then make tweaks. After a while often one of the pre-made profiles is good enough.
HDR output is present in ART, which is a fork of RawTherapee. But it is not really usable, as the preview will show the beyond-SDR areas as pure white or something like that. I.e., you will be working blind.
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?
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).
Yes you are completely right. This part is definitely not optimal yet. I haven't had lots of Tauri / Rust experience before this project.. it's on my todo list to improve. While trying to use the asset localhost protocol I ran into a lot of permission issues.
I didn’t know the developer is 18. No snark intended. Great work. Slow or suboptimal code is common nowadays, and often it’s better to get it working before worrying about speed.
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.
If you haven’t tried ansel: https://ansel.photos/en/ or darktable: https://www.darktable.org/ I’d recommend trying them out - they are the current open source raw editing apps that perform well that are out there. It could be that this app is competitive with them, but I haven’t had a chance to try it out yet - but both ansel and darktable run well on my M1.
While certainly an impressive effort, it's not even close to competitive yet. As is pointed out in a comment on [1] and as can be seen from the rat piss yellow in the sky, the algorithms are very much on the naive/simple side of things.
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.
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.
Check out color.io for reference. It is a color grading focused app but nevertheless has bells and whistles for many workflows regarding raw photos. The thing is that it is offline, runs on browser, and is much faster than Rawtherapee or Darktable on my aging PC.
It’s not "web" in a way you mean that, it uses rust and gpu processing very heavily, up to the point where it just launched by web browser and that’s it
We need an easy to use RAW editor. For a long time I used Darktable, with default settings I would get images that where close to the camera jpeg. I just had to change in what artistic direction I wanted to go. With update after update I had to fight to even get decent skin colors.
Currently on a pirated copy of CaptureOne, but would rather use something open source (Or buy something affordable)
Do you have default camera and lens profiles build in?
He's no doubt a talented young man as well. Google Gemini would be much less helpful in many other people's hands; kudos to him. That said, at some point the people so dismissive about the capabilities of current AI systems, will have to admit that they're quite powerful indeed, even with their limitations.
Thank you for the feedback. Yes - Gemini was a big help but as I also work / train LLM's I know very well how to use them and their limitations. With this, I can use them much more efficiently.
Running it on Windows 10 / AMD RX 6900 XT, and the app is extremely slow, dragging the window, adjusting any sliders takes considerable amount of time with 6000x4000 DNG files...
I find it absolutely bizarre that people post about stuff they are seemingly have no idea about. Like, code signing & notarization provides clear quality of life improvement for many users. And your reasons are just plain wrong.
1. 100$ is a pocket change for many people. Depending where you live. I think it is enough of a barrier to force a thoughtful action. Also, to compare, cheapest certificates for signing windows software are like 450$/year. Microsoft has a hosted service now for $15/year, but that is still in beta. Both of those options are significantly more expensive than 99$/year Apple charges.
2. No, Apple does not deny randomly access to developer accounts. Also, this is quite besides the poin.
3. Code Signing has absolutely nothing to do with submitting your app to app store, or anything Apple has to approve of. Like, why even write about something you have no idea about?
100$ a year is a lot of money if you aren't planning I'm selling anything. The instructions to build from scratch or run it without signing aren't difficult.
I've literally had to argue with Apple for months to get my account approved.
It was not a fun process, eventually they did grant me an account, but then just keep up an old hobbyist game I was wasting that 100$ a month.
I ended up just recompiling for WebGL and uploading to itch.
Going through the hoops for code signing and getting account doesn't make sense if OP isn't going to sell it on the app store.
Finally, it's not like this is the only raw editor.
How many people.
A: Will pick an open source feature lite raw editor which isn't going to be as good as Darktable or Lightroom.
And
B: Aren't willing to build from source or literally run a single terminal command to run the unsigned version.
Now, if OP wants to sell it on the app store then I'm completely wrong. But otherwise it's not a good use of time.
You're free to reach out to OP and offer them 100$ + another 300$ for time spent having to apply for a Developer account.
They are different lossless image formats. What is called "raw" is quite a few different formats from different manufacturers, and they contain lossless image data from the camera sensor without significant postprocessing. They usually need some postprocessing to look "good". A "bitmap" is just pixel data, not a file format, but .bmp is a file format, which does support some compression, and usually won't contain raw camera sensor data but something ready to be displayed on a screen.
No an expert here but RAW is the data generated by the sensor and requires some heavy processing before you can show it on screen. A bitmap is an image format (assuming you mean the BMP files).
A big difference is bit depth. BMP normally is 8bits per pixel per channel (colour). RAW is often more bits (say 10 or 12 or even more). This means you can adjust lighting without introducing banding and so on.
most importantly a RAW file hasn't been demosaiced, ie instead of pixels of colors, it's a grid of scalar sensor measurements that, depending on the pattern (eg Bayer) each represent either red, green or blue intensity. since we only know one for each position in the image, the other two have to be interpolated (which is demosaicing)
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.
Great, so if I use an app that creates XMP files, this app is going to create a second sidecar called rrdata. So I guess I could have amended that to the original question on why create a different sidecar than the images’ default.
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.
My folders do not have a series of sidecars written by Lightroom. The edits are stored within Lightroom’s library. I have other programs that use sidecar files, but Lightroom does not. Maybe it’s a preference, but I’ve never looked. If I move/rename a folder Lightroom was looking at, it asks me to relink it when I next open Lightroom. It’s not an earth shattering situation to fix.
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.
IME in photo post-processing, good UX, smooth multi-photo workflow and intuitive controls beat technical details every time.
RawTherapee is better than Darktable. But that’s a pretty low bar to clear. There are reasons people pay for Lightroom.
Partner is getting into photography and I don't have the stomach to purchase some software.
I threw darktable and rawtherapee on the table but without technical grit you get nowhere really fast.
It's no my wheelhouse so they are mostly in there own.
I've been getting into photography lately too and running into the same question. There's no way I'm getting an adobe subscription. But I'm not sure what tools do I want to pick up instead. Apple Photos has gotten me pretty far, but I'm hitting the limits of what it can do. And my photo library is getting pretty big now - big enough that I want some software to manage where my photos live as well.
> But I'm not sure what tools do I want to pick up instead. Apple Photos has gotten me pretty far, but I'm hitting the limits of what it can do.
Be sure to take a close look at Nitro, created by a former Apple lead of Apple's Aperture, iPhoto, RAW Camera and Core Image engineering teams: https://www.gentlemencoders.com/nitro-for-macos/index.html
Played with Nitro this morning and compared my edits to those that came out of Lightroom and my camper manufacture’s RAW software and am very happy with the results. It has a user friendly interface, which I prefer to Lightroom’s, and I love that it’s a one time purchase. Thanks for the recommendation
Glad to hear it, thank you for the update!
Arrrr, you be a pirate
Capture one?
That's also ridiculously expensive. The only value proposition is if you're sure you won't update for several years.
Firstly it's a matter of reliably storing image files. I just make a new folder in the file system — each-time I transfer image files from camera to computer — named as the transfer-date YYYYMMDD. I wrote a 10-line script to give those image files unique-sequence-names YYYYMMDD-00N.ext.
So when I mistakenly copy into the wrong folder, it's obvious which image files don't belong. So I don't need to delay while I think of the best descriptive folder name. So I don't need to sort yesterdays photos into a different folder than todays photos.
Secondly it's a matter of deleting image files. I take a look with some viewer app and use the file system to delete whatever doesn't seem worth any more attention.
Thirdly whatever trial photo software is available is probably good enough to start learning.
Pixelmator pro is nice on the Mac, and it's a one time purchase, not even expensive. And CameraBag was not bad last time I tried it, also a one time purchase.
IME GUI is mainly important when you craft a new profile. In many workflows, you don’t do it very often. I create a profile once and then apply it to hundreds of frames without launching the GUI at all or mostly using it just to preview how the profile works with a particular frame and make a couple of minor tweaks.
I used RawTherapee a ton, but changed to Lightroom because the denoising is so much better. (I’m sure a more expensive camera would also help here, but I have what I have.) Now that I’m used to Lightroom it will be hard to switch back.
Yeah, LR's denoising is chef's kiss. It's much better than what Canon's own raw processor can do, for example.
Another thing I noticed with RawTherapee after LR was the sloooowness. Lightroom has been super optimized to show all edits (or their preview versions anyway) in real time.
Because those open-source editors are made by coders, not photographers.
Those tools you really need for properly edit raws are hidden in blated features (multiple demosaic algorithms) or completely missing (AI masking). And UI is not user friendly.
They are made by and for photographers. This software is designed for many use cases, not just creative photography - hence multiple demosaicing algorithms. AI masking is missing exactly because it's made by photographers - they don't have the required expertise. UI is not intuitive because a) it's designed by photographers' committee, not UI designers, and b) you are familiar with a completely different workflow.
Most photographers don't know how develop software at all.
Please explain why photographers need 20 differnet sharpening methods, 5 demosaicing algorithms, many colour corrections that are almost useles if AI masking is not present?
Coders often lost in all kind of geeky features that missing actual usability by targeted audience. Bloated software is not what I would expect from alternative to commercially used proprietary software.
Because it's not necessarily about creative/artistic photography, it's also for things like e.g. microscopy or negative or scan processing, and it's not an alternative to Lightroom which does "magic" unacceptable in many technical use cases.
You can ignore features that aren't made for you, and actually I think they're mostly hidden by default in DT (make a preset if you don't like the default tool selection). All these features were added because somebody needed them at some point, the DT/RT/ART communities are chaotic and lack vision but they're actually using their stuff.
>Coders
As I said, this is not software made by coders for coders. This is exactly how the software made by photographers would look if they lacked organization, focus, and UX skills. If it was made by coders (and UI designers), it would probably have looked like Lightroom and had AI selection.
You can ignore features that aren't made for you
Another terrible design in darktable is default settings. I have no problem with options, but then you need carefully choose defaults that are selected questionable here - pure exhibitionism right after opening software.
I don't agree with your statement about developing by photographers. If so, there is higher probability that they would focus on UI with more aesthetic care than coders would do.
Lack of AI masking is too expensive to use by professionals. You simply cannot afford to mask manually bunch of images. Wider adoption among photographers is simply impossible.
why can't they be both photographer and coder?
I mostly prefer RawTherapee's processing, with one exception: Darktable's stupidly good "filmic" emulation can beautifully recover overexposed raws that I thought were trash. It manages to make it easy to shift the entire scene one or two stops darker with just a few clicks (yes, there is data up there in raws).
I have not found an equivalent mechanism in RawTherapee. Does anyone know if it has an equivalent tool?
https://rawpedia.rawtherapee.com/Exposure#Highlight_Reconstr...
Parent was not talking about highlight reconstruction.
DT has a highlight reconstruction module too but RTs was superior every time I tried.
They're talking about the Filmic module which is a fancy exposure adjustment curve. I ported it to Rust for use in our internal 2D compositing renderer (not open, unfortunately). That's when I got to appreciate the work done there, really.
The gainforge crate has another port, although not with all parameters of the original algorithm, AFAIR.
The algorithm is explained in a blog post by the author of the module. [1]
Who is btw. the same guy that got fed up with DT dev and forked it to Ansel.
[1] https://eng.aurelienpierre.com/2018/11/filmic-darktable-and-...
Thanks for the correction. After reading the reference I don't feel the need to pursue what seems a bit like a quest.
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).
https://github.com/aurelienpierreeng/ansel there's also a fork to play with
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).
I do a lot of mild re-lighting. If RawTherapee had the path masks from darktable I'd be more than happy.
One way could be exporting lossless 16-bit TIFF or PNG from RT, in some wide colour space and without sharpening, and then doing relighting + final processing steps in another tool… However, if you want to apply a CLUT after relighting then yeah, tricky.
It would be great if RT supported something along the lines of “take the entire canvas after initial raw processing but before CLUT and final touches and put it into a temporary file; allow me to do something with it in any other tool; then load it back and apply the rest of the steps on top of that”, but that might require it to store that edited canvas somewhere in addition to .pp3 file.
Can't stand roundtrips anymore. Yup, I actually apply a LUT after tone mapping in darktable.
Well, it’s not a roundtrip if you just feed the output to another tool. My processing script typically pushes RT-prepared PNG to something like ffmpeg which may do resizing and more, depending on the end format.
ART (Another RawTherapee) has a more Lightroom-like approach to masking that you might like better.
RawTherapee is great in most ways, except that all of the curves for adjusting anything have absolutely catastrophically bad handling. It's so amazing having access to the Lab colour adjustments but the sliders are abysmal, impossible to make any kind of precise adjustments, impossible to reset an individual slider/point back to it's default placement, impossible to undo the last action without resetting the entire widget to its default state. It's unusable, and I'm convinced that the popularity of it would skyrocket if they'd finally just sit down and address that it's miserable to use. I would drop lightroom in a heartbeat if they made them even a little bit better.
I know it's a different space, but as a counterexample, FabFilter makes audio plugins that are the gold standard for that kind of interface and it isn't even close. Anybody making an interface for interacting with points on a curve should sit down with the free demo of FabFilters Pro-Q3 for just a few minutes to experience what's actually possible and how it should feel.
> impossible to make any kind of precise adjustments
That claim does not match my experience in any way.
For example, Control Cage curves have node value adjustment to 1/1000th.
https://rawpedia.rawtherapee.com/General_Comments_About_Some...
I think control cage or parametric curves can be quite precise…
https://github.com/RawTherapee/RawTherapee
> 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).
Language pedantry has nothing to to with photographic image processing expertise and if anything this would be a sign that the developers care more about being "right" than what users want.
I disagree; it shows understanding of subject area.
I like this one its simple and easy to use
May I ask why choose to shoot raw given simplicity and ease of use are priorities?
Those are certainly not mutually exclusive! The point of shooting raw is not to painstakingly tweak super-technical details, it’s to get processing latitude to make photos the way you want. Often that involves simple adjustment of shadows, highlights, saturation and so on, applied to a large number of photos in bulk.
The priorities are mutually exclusive: delegating scene data conversion to in-camera engine grants you the most simplicity and ease of use at the expense of control; the territory of technical details grants you the most ability to make the photos looks the way you want at the expense of simplicity. You dial one up, you dial the other down.
For example, your choice of demosaicing method can make a tangible difference in finer details: some methods would make them less noisy (better for some styles), others would better preserve finer details (better for other styles). Abstracting it behind one “more detail—less detail” slider isn’t going to work because “detail” can mean a multitude of things, of which sometimes you want one and not the other, and inventing new sliders with user-friendly but inscrutable labels a la “brilliance”, “texture”, and so on, can only get you so far.
There are shades between simplicity vs. control, of course, and so I am curious to know the answer from the horse’s mouth so to speak: to what end they choose to compromise simplicity.
It’s a case of diminishing returns. Shooting raw is a huge and obvious improvement if you want to post-process in almost any way. Conditional on that the workflow should be as smooth and simple as possible. Abstract controls like "clarity" are fine if the result of adjusting them is tangible and almost always does what you want. Giving the user lots of knobs that hardly have a visible effect (let alone a desired effect) is not an improvement.
Almost no professional photographer will care about the intricacies of the demosaicing algorithm, or the choice between a dozen different denoising modules, and Lightroom is entirely correct in not giving you a zillion knobs to adjust things that have no effect on image quality except in the rarest of cases. In 99% of cases the controls that matter are:
* Basic exposure/shadows/contrast etc
* Curves/levels for more control if needed
* White balance
* Cropping, obviously
* Cloning/healing brush
* Simple knobs for sharpening and NR
* Level/perspective adjustment
* Lens aberration correction (most of the time no manual input needed if the lens is in the batabase)
> Shooting raw is a huhe and obvious improvement if you want to post-process in almost any way.
See, you are saying “want to post-process”, which to me says that there is a different priority present rather than just “simplicity and ease of use”.
If the priority is “making the photos look the way you want them to look”, then we are in a territory where it is not as simple as “this tool is easy to use and therefore a better choice than that tool”.
It's not binary.
You can want post-processing, but also don't want to spend 50 hours to learn a tool. Sometimes you just want "make it look close to the in camera jpeg, but let me adjust to exposure"
It's not that complex.
It’s not binary is the point and the whole reason I asked the original commenter why put premium into simplicity and ease and then immediately violate that by shooting raw.
Do you understand him now?
Without him or her answering my question? Hardly.
He, or rather we, want access to most of the benefits of editing raw files, but with an easy to learn UX. Even if it means giving up on the last 10%.
This concept is pretty common, not even limited to photography.
When is the priority not “making the photos look the way you want them to look” ?
When you say “simplicity and ease of use” I think that includes taking the photos, and if I can defer some decisions that might make the overall process simpler.
I'm not the person you're responding to, but in my hobby experience it's sometimes the difference between a photo being fine or even great, and being completely unusable.
If the white balance is set wrong in-camera, then the JPG just came out all blue. It's effectively a black and white photo (albeit in shades of blue), and there's nothing to be done about it. Shot in RAW, the photo can be made color again, extremely easily and quickly.
In fact it gets worse, not better, if you on the day try to adjust the white balance, as you go from outdoors to indoors. Not to mention if you change from flash and back. Auto is safer, but when it's wrong, the photo is unusable, and the moment is gone.
But my DSLR is now over a decade old. Maybe "auto" has gotten much better?
So yeah, for me the main thing is to be able to post facto adjust white balance, which JPG does not support. (if you've done it with both JPG and RAW, you know what I mean when I say "does not support")
Right, I suppose shooting raw is good because you need to think less about your settings at shooting time.
I will say that “auto” is pretty decent on the phones in most common lighting scenarios like sunlight/shade/outdoor/tungsten/fluorescent—white point is an entirely subjective thing that cannot be reliably determined automatically, so in my experience you rarely get the correct rendition of, say, bright pink clouds at sunset, or a book with pink pages (the phone would think it must be the some weird lighting that should be corrected for, because obviously a book can only have nearly white pages, right?), etc.—but due to physical limitations of sensor size and inferior optics the phone is worse than even a decade-old APS-C DSLR in most regards overall.
I do think auto white balance is a little better these days. My old DSLR often had a strong magenta tint magenta in scenes with a lot of green (like forests). My new mirrorless camera from the same manufacturer no longer does that.
> The priorities are mutually exclusive: delegating scene data conversion to in-camera engine grants you the most simplicity and ease of use at the expense of control; the territory of technical details grants you the most ability to make the photos looks the way you want at the expense of simplicity.
The camera makes all those decisions even when shooting raw -- and there are stored in the raw file. So, by default, processing a raw file witout doing any tweaks will get you the jpeg you would have gotten.
My camera (Nikon) -- and I assume the others -- will even store both the RAW and the JPEG, so you don't even have to go through the automatic conversion step if you don't want to.
There's no inherent usability issue with shooting RAW. My experience has been that none of the open source tools can hold a candle to the proprietary ones.
RawTherapee I uninstalled almost immediately because it crashed a few times and the UI didn't seem to jive with what I wanted to do.
Despite DarkTable's horrific interface and hostile developers I keep it around because I can often beat it into submission (but what a chore that is). And that's the thing. Even if I were shooting JPEGs DT's interface would still be a problem.
I fought darktable for two years before feeling right at home. I had used Lightroom since it's inception. I'm happy now I invested the time. I much prefer the control darktable gives me now.
It's not about not "feeling right at home". I've detailed this in other comments but it's just that DT has an abysmal interface and that the devs insist that it needs to be complex. This sort of hostile attitude is part of what spawned Ansel.
This is a bit of a myth.One of my complaints dealt with how unintuitive the sliders are. There's no additional control gained by making the UI widgets difficult to deal with.
Another dealt with trying to set color temperature. There are two places color temperature can be set and they'll both conflict with each other. The newer module is absurdly complex. It's great if you're writing a dissertation on color rendition but less great if you're trying to be productive.
Sure there's more control offered by having ten different demosaicing algorithms to choose from. Unfortunately I can't think of a time when I've needed or wanted that control. Maybe if I shot Fuji or Sigma. But I don't. And most folks don't.
Presets and history are a nightmare. Items in the history widget get aggregated so it's difficult/impossible to pick out individual steps. If you give labels to the actions in a preset (my terminology is off because I've not used DT much in a while)… sometimes they work. Sometimes they don't and things don't appear to pick up the label/group/whatever it's called. If memory serves I had to apply presets in one module to have them visible in the develop module.
The vestigial DAM stuff… ugh.
There's no obvious A/B split views.
Perhaps the most obnoxious thing is that DT shamelessly apes the Lightroom interface but in reality behaves almost nothing like Lightroom. There's a TON of complexity for little-if-any improvement in outcomes.
First, let me concur that Darktable is not great. I found it to be neither quite as simple as Lightroom, nor as powerful as RawTherapee, and severely lacking in documentation.
> Another dealt with trying to set color temperature. There are two places color temperature can be set and they'll both conflict with each other.
There are at least three colour temperature / white balance controls in RT; more if you count output colour space primaries, Lab space curve, etc. as ways of creative white balance control.
I’m not sure I see any particular conflict between them. They all do different things; some of them are more relevant if you want to achieve the most precise representation (e.g., you are digitizing analog prints or paintings), others are more relevant if you are going for a creative look of your own.
It’s probably best to consult RawPedia[0], but as far as I understand:
— One of them controls raw data interpretation, and affects how different tools work down the line (e.g., highlight recovery or targeting sky with wavelets). As far as I understand, you probably want to keep this one technically correct and as close as possible to the true neutral white/grey point; at this step you are helping the tool do the rest of its job and not trying to achieve a look. If you use a colour card, a DCP profile, etc., then you know exactly what to set White Balance controls to.
— There are a couple of controls under CAM model, which you may or may not be using depending on your profile. With scene illuminant you set… well, scene illuminant (the light you have in your scene), and viewing conditions allow you to shift colours to make it look right if you know your photo will be viewed in an environment with particular light.
— Then, of course, you have dozens of different ways of creatively controlling perceived white balance via different curves or CLUT; I think these are most handy if you are going for a look.
[0] https://rawpedia.rawtherapee.com/White_Balance
> I’m not sure I see any particular conflict between them.
I don't have DT under hand to check, but there are two controls which, if active at the same time, will produce a warning along the lines of "wb is already set in [the other control]".
edit: I think [0] describes the issue
[0] https://discuss.pixls.us/t/white-balance-applied-twice/34949
I see, that explains why DT is confusing in this regard.
The problems I listed were for Darktable. If you use the stock configuration and go into the "white balance" module you will get an error. If memory serves turning off the "white balance" module also leads to problems. Instead you're expected to go into the "color calibration" module. More powerful? Perhaps. Unnecessarily obtuse? Absolutely.
I tried Rawtherapee first as they actually sign their (macOS) app. Unfortunately it was too unstable to be useful.
I wonder specifically what you mean by "too unstable" and how long ago that was, because I haven't had problems with RawTherapee on MSWin.
(Later versions may have moved newer functionality to a different tab or menu item, is that what you mean?)
I try to daily drive Linux but can't find a simple / nice to use RAW editor. I had high hopes for Darktable but I was astonished how bad the GUI is. When trying to delete photo, it deletes the photo under the pointer, not the photo I selected... WTF ?!? And the whole app feels so complicated... Then there's forks emerging and the dev forces are diluted in multiples applications and Adobe continues to milk its users because Open Source dev can't work together. Between Shotwell, Gthumb, Loupe, RT, DigiKam, and more... Imagine if all this efforts was done in one cohesive app ? Ok I stop dreaming.
If you seek a GUI for managing/cataloguing photos, my advice would be to look for that and not a raw image processing tool that incidentally happens to also handle cataloguing (inevitably in a half-baked way).
I have never seen Lightroom (or C1, for that matter) as compelling at all ever since I started using RawTherapee. Unlike, say, InDesign, which is legitimately a difficult to replace professional tool with incredible capabilities, Adobe’s raw image processing offering looks incredibly dumbed down.
Yes good point. But my needs are very limited. On macOS I use the Photo app to cull, make small adjustments, and crop. On Windows there is also a Photo app that allows such basic features. They both works with RAW and works fine with my NAS mount in smb to cull directly the files (though macOS is a pain for that, doesn't play well with files, need to import in lib).
On linux, the default Gnome image viewer is nice but you can't make adjustement and when deleting a file, the file is not remove from the NAS directory (need a manual refresh). With Gthumb it works for deleting files but the crop tool and the overall app is not as nice. Anyway I'll continue to look for my perfect app or for the default Gnome viewer to update its features (I think it is in active development)
It sounds like you would really like DigiKam! Great library management, and solid basic editing functionality. Optional face detection as well.
I windows I highly recommend IrfanView just for basic photo viewing (odd name). It's extremely fast.
Yes I've used it and it's very good. Too bad it's not on Linux and macOS.
Maybe take a look at GraphicConverter for the Mac. While it isn't a file Management tool, it's really useful for tweaking various details.
https://en.wikipedia.org/wiki/GraphicConverter
About the worst thing I can say about Lightroom is that it didn't reliably work with my iPhone. Otherwise it did everything I needed in terms of tagging, presets, and organizing the pictures on the file system.
Meanwhile darktable creates freaking sidecars for every picture while it relies on an SQLite database for tracking history just like Lightroom does.
Conversely Darktable is the best advert I've seen for Lighgtroom.Maybe Lightroom is okay for cataloguing, I cannot say because I have not used it this way extensively, but it is not up to par in terms of raw processing control in my view.
That insane behavior around acting on the highlighted image instead of the selected image has finally been fixed: https://github.com/darktable-org/darktable/issues/16850#issu...
Filmulator (I really need to fix the CI...)
It’s just “raw”, it’s not an acronym.
I have the same approach. I really like "easy to use, hard to master" tools in general.
If you look at CaptureOne you can see how easy it is to edit a raw image. Most of the time it looks like the camera jpeg without having to tune anything. But then you have the options to go in depth.
Sometimes I have a photo session where everything is to my liking, just a bit of exposure and crop. Other times I shoot in night clubs with no flash and I have multiple layers of masks for a single photo.
A UI with decent defaults goes a long way into making a complex app easy to use.
This tracks with my RawTherapee experience. I copy in base settings corresponding to the camera and the lens and then make tweaks. After a while often one of the pre-made profiles is good enough.
For example — Adobe\CameraRaw Sony SLT-A65 Adobe Standard.dcp ?
By “pre-made” I meant ones I have created previously, if that is what you mean.
HDR output is present in ART, which is a fork of RawTherapee. But it is not really usable, as the preview will show the beyond-SDR areas as pure white or something like that. I.e., you will be working blind.
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).
Yes you are completely right. This part is definitely not optimal yet. I haven't had lots of Tauri / Rust experience before this project.. it's on my todo list to improve. While trying to use the asset localhost protocol I ran into a lot of permission issues.
6x sounds bad. Might be a sign of vibe coding?
>React and Rust, with the support from Google Gemini
>immensely grateful for Google's Gemini
>AI Studio's free tier
I didn’t know the developer is 18. No snark intended. Great work. Slow or suboptimal code is common nowadays, and often it’s better to get it working before worrying about speed.
na, electron/tauri/"the web" has done this long before GPT happened.
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
If you haven’t tried ansel: https://ansel.photos/en/ or darktable: https://www.darktable.org/ I’d recommend trying them out - they are the current open source raw editing apps that perform well that are out there. It could be that this app is competitive with them, but I haven’t had a chance to try it out yet - but both ansel and darktable run well on my M1.
While certainly an impressive effort, it's not even close to competitive yet. As is pointed out in a comment on [1] and as can be seen from the rat piss yellow in the sky, the algorithms are very much on the naive/simple side of things.
[1] https://youtube.com/watch?v=7QymsCRNRHE
Capture One I always thought was highly underrated and still easy to use. And I've never used of their PhaseOne cameras
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.
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.
In my opinion, a web based UI for something like an image editor is a bad idea. It will be slow and resource intensive.
Check out color.io for reference. It is a color grading focused app but nevertheless has bells and whistles for many workflows regarding raw photos. The thing is that it is offline, runs on browser, and is much faster than Rawtherapee or Darktable on my aging PC.
It’s not "web" in a way you mean that, it uses rust and gpu processing very heavily, up to the point where it just launched by web browser and that’s it
I couldn't immediately find information about how the metadata is stored? Is it one shadow file per RAW file, as I've seen in other OSS RAW editors?
I'm not sure what the perfect solution is, but it is hard to sync a ton of shadow files to cloud storage, versus one big catalog file.
Is the metadata in an open format, so I can take the edits to other programs?
I am glad there's alternatives to having to shell out for Light Room every month. I only need to edit RAW files after holidays!
Neat.
We need an easy to use RAW editor. For a long time I used Darktable, with default settings I would get images that where close to the camera jpeg. I just had to change in what artistic direction I wanted to go. With update after update I had to fight to even get decent skin colors.
Currently on a pirated copy of CaptureOne, but would rather use something open source (Or buy something affordable)
Do you have default camera and lens profiles build in?
Wild, I was literally just today looking at this repository to see how I could do raw image thumbnailing in Rust. Coincidences...
> a personal challenge at the age of 18 ... with the support from Google Gemini
I'm no AI fanboy, but it's neat to see some dreams come true because of it.
He's no doubt a talented young man as well. Google Gemini would be much less helpful in many other people's hands; kudos to him. That said, at some point the people so dismissive about the capabilities of current AI systems, will have to admit that they're quite powerful indeed, even with their limitations.
Thank you for the feedback. Yes - Gemini was a big help but as I also work / train LLM's I know very well how to use them and their limitations. With this, I can use them much more efficiently.
I found it unnecessary to highlight their age.
Yeah me too, sometimes it feels like some marketing technique that I’m not aware the purpose of it.
Running it on Windows 10 / AMD RX 6900 XT, and the app is extremely slow, dragging the window, adjusting any sliders takes considerable amount of time with 6000x4000 DNG files...
Is there a System Requirements page? What's the minimum OS version required?
Looks very interesting. How much work would it be to get this code signed for the Mac?
Not much, but you might want to donate to help the author offset the Apple Developer account cost :^)
I think it's pretty simple. I'm just focused on the core features right now but I definitely plan to sign it in the next 1-2 weeks. Thanks :)
I wouldn't make the Apple Developer dance a priority unless you intend to sell a commercial signed version.
Few reasons.
1. It's 100$ a year, which isn't pocket change when it's making you no revenue.
2. Apple likes to randomly deny developer accounts.
3. They have no issue with outright rejecting apps with vague reasoning.
4. Plenty of high quality raw editing apps already exist for OSX.
If someone really wants to use it on OSX you've provided clear instructions.
I find it absolutely bizarre that people post about stuff they are seemingly have no idea about. Like, code signing & notarization provides clear quality of life improvement for many users. And your reasons are just plain wrong.
1. 100$ is a pocket change for many people. Depending where you live. I think it is enough of a barrier to force a thoughtful action. Also, to compare, cheapest certificates for signing windows software are like 450$/year. Microsoft has a hosted service now for $15/year, but that is still in beta. Both of those options are significantly more expensive than 99$/year Apple charges.
2. No, Apple does not deny randomly access to developer accounts. Also, this is quite besides the poin.
3. Code Signing has absolutely nothing to do with submitting your app to app store, or anything Apple has to approve of. Like, why even write about something you have no idea about?
4. True. Not sure how it is relevant.
100$ a year is a lot of money if you aren't planning I'm selling anything. The instructions to build from scratch or run it without signing aren't difficult.
I've literally had to argue with Apple for months to get my account approved.
It was not a fun process, eventually they did grant me an account, but then just keep up an old hobbyist game I was wasting that 100$ a month.
I ended up just recompiling for WebGL and uploading to itch.
Going through the hoops for code signing and getting account doesn't make sense if OP isn't going to sell it on the app store.
Finally, it's not like this is the only raw editor.
How many people.
A: Will pick an open source feature lite raw editor which isn't going to be as good as Darktable or Lightroom.
And
B: Aren't willing to build from source or literally run a single terminal command to run the unsigned version.
Now, if OP wants to sell it on the app store then I'm completely wrong. But otherwise it's not a good use of time.
You're free to reach out to OP and offer them 100$ + another 300$ for time spent having to apply for a Developer account.
What is the difference between RAW and Bitmap. I thought Bitmap had no compression
They are different lossless image formats. What is called "raw" is quite a few different formats from different manufacturers, and they contain lossless image data from the camera sensor without significant postprocessing. They usually need some postprocessing to look "good". A "bitmap" is just pixel data, not a file format, but .bmp is a file format, which does support some compression, and usually won't contain raw camera sensor data but something ready to be displayed on a screen.
No an expert here but RAW is the data generated by the sensor and requires some heavy processing before you can show it on screen. A bitmap is an image format (assuming you mean the BMP files).
A big difference is bit depth. BMP normally is 8bits per pixel per channel (colour). RAW is often more bits (say 10 or 12 or even more). This means you can adjust lighting without introducing banding and so on.
most importantly a RAW file hasn't been demosaiced, ie instead of pixels of colors, it's a grid of scalar sensor measurements that, depending on the pattern (eg Bayer) each represent either red, green or blue intensity. since we only know one for each position in the image, the other two have to be interpolated (which is demosaicing)
Very nice, I will probably join your efforts on the project.
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.
Aren't edits app-specific anyway? Last I tried (a month or so ago) sharing edits between darktable and lightroom didn't exactly work.
Great, so if I use an app that creates XMP files, this app is going to create a second sidecar called rrdata. So I guess I could have amended that to the original question on why create a different sidecar than the images’ default.
That's why I love DNGs. No Sidecar file to lose! Just one file, and still non-destructive.
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.
My folders do not have a series of sidecars written by Lightroom. The edits are stored within Lightroom’s library. I have other programs that use sidecar files, but Lightroom does not. Maybe it’s a preference, but I’ve never looked. If I move/rename a folder Lightroom was looking at, it asks me to relink it when I next open Lightroom. It’s not an earth shattering situation to fix.