[HN Gopher] RapidRAW: A non-destructive and GPU-accelerated RAW ...
___________________________________________________________________
RapidRAW: A non-destructive and GPU-accelerated RAW image editor
Author : l8rlump
Score : 251 points
Date : 2025-07-09 02:37 UTC (20 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| mrbluecoat wrote:
| > 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.
| tux1968 wrote:
| 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.
| cybertimom wrote:
| 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.
| kookamamie wrote:
| I found it unnecessary to highlight their age.
| rrgok wrote:
| Yeah me too, sometimes it feels like some marketing technique
| that I'm not aware the purpose of it.
| dylan604 wrote:
| 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.
| cybertimom wrote:
| 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.
| dylan604 wrote:
| 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.
| ethan_smith wrote:
| 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.
| vladvasiliu wrote:
| Aren't edits app-specific anyway? Last I tried (a month or so
| ago) sharing edits between darktable and lightroom didn't
| exactly work.
| runxel wrote:
| That's why I love DNGs. No Sidecar file to lose! Just one
| file, and still non-destructive.
| dylan604 wrote:
| 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.
| Xevion wrote:
| Wild, I was literally just today looking at this repository to
| see how I could do raw image thumbnailing in Rust.
| Coincidences...
| bjelkeman-again wrote:
| Looks very interesting. How much work would it be to get this
| code signed for the Mac?
| notpushkin wrote:
| Not much, but you might want to donate to help the author
| offset the Apple Developer account cost :^)
| cybertimom wrote:
| 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 :)
| 999900000999 wrote:
| 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.
| polishdude20 wrote:
| 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?
| kamranjon wrote:
| 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.
| donatzsky wrote:
| 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
| cybertimom wrote:
| 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
| TheDong wrote:
| 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).
| rossant wrote:
| 6x sounds bad. Might be a sign of vibe coding?
| ImGonnaVibeCode wrote:
| >React and Rust, with the support from Google Gemini
|
| >immensely grateful for Google's Gemini
|
| >AI Studio's free tier
| maverwa wrote:
| na, electron/tauri/"the web" has done this long before GPT
| happened.
| cybertimom wrote:
| 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.
| miladyincontrol wrote:
| 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.
| strogonoff wrote:
| 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.
| mikae1 wrote:
| 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).
| strogonoff wrote:
| 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).
| mikae1 wrote:
| I do a lot of mild re-lighting. If RawTherapee had the path
| masks from darktable I'd be more than happy.
| strogonoff wrote:
| 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.
| mikae1 wrote:
| Can't stand roundtrips anymore. Yup, I actually apply a
| LUT after tone mapping in darktable.
| strogonoff wrote:
| 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.
| donatzsky wrote:
| ART (Another RawTherapee) has a more Lightroom-like approach
| to masking that you might like better.
| actionfromafar wrote:
| https://github.com/aurelienpierreeng/ansel there's also a
| fork to play with
| babuloseo wrote:
| I like this one its simple and easy to use
| strogonoff wrote:
| May I ask why choose to shoot raw given simplicity and ease
| of use are priorities?
| Sharlin wrote:
| 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.
| strogonoff wrote:
| 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.
| knorker wrote:
| 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")
| strogonoff wrote:
| 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.
| GrayShade wrote:
| 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.
| Sharlin wrote:
| 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)
| strogonoff wrote:
| > 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".
| Mashimo wrote:
| 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.
| strogonoff wrote:
| 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.
| Mashimo wrote:
| Do you understand him now?
| igouy wrote:
| 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.
| timmg wrote:
| > 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.
| inferiorhuman wrote:
| 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.
| mikae1 wrote:
| 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.
| inferiorhuman wrote:
| 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.
| strogonoff wrote:
| 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
| vladvasiliu wrote:
| > 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
| strogonoff wrote:
| I see, that explains why DT is confusing in this regard.
| inferiorhuman wrote:
| 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.
| igouy wrote:
| 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?)
| Nergg wrote:
| 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.
| strogonoff wrote:
| 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.
| Nergg wrote:
| 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)
| Melatonic wrote:
| I windows I highly recommend IrfanView just for basic
| photo viewing (odd name). It's extremely fast.
| Nergg wrote:
| Yes I've used it and it's very good. Too bad it's not on
| Linux and macOS.
| jcynix wrote:
| 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
| inferiorhuman wrote:
| 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.
| CarVac wrote:
| Filmulator (I really need to fix the CI...)
| daturkel wrote:
| 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...
| strogonoff wrote:
| It's just "raw", it's not an acronym.
| Mashimo wrote:
| 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.
| strogonoff wrote:
| 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.
| igouy wrote:
| For example -- Adobe\CameraRaw Sony SLT-A65 Adobe
| Standard.dcp ? DCP Tone curve
| DCP Base table DCP Look table
| Sharlin wrote:
| 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.
| strogonoff wrote:
| 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.
| simonmales wrote:
| 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.
| dsego wrote:
| 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.
| josephg wrote:
| 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.
| Mashimo wrote:
| Arrrr, you be a pirate
| CharlesW wrote:
| > _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
| t0bia_s wrote:
| 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.
| orbital-decay wrote:
| 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.
| t0bia_s wrote:
| 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.
| orbital-decay wrote:
| 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.
| knowitnone wrote:
| why can't they be both photographer and coder?
| Jaxan wrote:
| 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.
| account42 wrote:
| > 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.
| thrtythreeforty wrote:
| 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?
| igouy wrote:
| https://rawpedia.rawtherapee.com/Exposure#Highlight_Reconstr.
| ..
| virtualritz wrote:
| 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-...
| igouy wrote:
| Thanks for the correction. After reading the reference I
| don't feel the need to pursue what seems a bit like a
| quest.
| sitkack wrote:
| https://github.com/RawTherapee/RawTherapee
| patrakov wrote:
| 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.
| roblh wrote:
| 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.
| Springtime wrote:
| 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.
| dxroshan wrote:
| In my opinion, a web based UI for something like an image editor
| is a bad idea. It will be slow and resource intensive.
| pvdebbe wrote:
| 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.
| zero_bias wrote:
| 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
| brcmthrowaway wrote:
| What is the difference between RAW and Bitmap. I thought Bitmap
| had no compression
| cfn wrote:
| 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).
| mkl wrote:
| 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.
| Jaxan wrote:
| 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.
| Mashimo wrote:
| 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?
| rkagerer wrote:
| Is there a System Requirements page? What's the minimum OS
| version required?
| ioma8 wrote:
| Very nice, I will probably join your efforts on the project.
| pradn wrote:
| 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!
| Melatonic wrote:
| Capture One I always thought was highly underrated and still easy
| to use. And I've never used of their PhaseOne cameras
| vsviridov wrote:
| 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...
___________________________________________________________________
(page generated 2025-07-09 23:01 UTC)