My camera has the option to output a RAW file (alongside the JPEG). I wonder if there could be any use of that file for non-professional folks like myself. I don’t plan to post process, but I want the most quality for my photos.
Example: Pull the data from the RAW file instead of compressing it to JPEG, and use more sophisticated algorithms to compress to JPEG XL or AVIF and get more quality for the same sized file.
Another possibly silly example is to shoot in RAW, and let a more sophisticated algorithm do the jpeg conversion in a more powerful computer with no time restraints later on, instead of leaving it up to the camera to do it with limited hardware and time. Is that even doable?
Yes, that is doable. A lot of image editing software has auto settings, or automatic retouching/cropping/straightening/… which can be applied to RAW files. Those may or may not be better than what your camera does internally.
Or export straight from RAW to the target medium/resolution skipping multiple compression passes.
Or getting an HDR 10 bit heic image from a photo you made 15 years ago when no one had an HDR screen.
Many photographers are now getting better exports from 10-20 year old images because they kept the RAW files. Who knows what the next years bring? I don’t really expect many changes in Bayer interpolation algorithms but I can see a move to other/better image formats and standards that the RAW file can be adapted to but a jpeg won’t. Most media still defaults to sRGB color, for example, when most displays today can do P3. If you only have the jpeg all that color and dynamic range information is gone (maybe a bit less if you use adobe RGB) but it’s all there in the RAW file.
So even if only for archival, or because photo editing tools can do a better automatic job, it is worth keeping the files. Or you might change your mind about post processing a file later on when you decide you want to have a nice print. Storage is cheap, a 1TB drive can hold 10.000 - 50.000 RAW files. If you need more than that you’re a pro and you should be able to afford it, or you should cull your images a bit.
If you want the most quality, you will need to post process. Not so much for ‘resolution’ but for colors, dynamic range, retouching some stuff, etc. Camera exports will always (depending on your settings) hover between a file that is too ‘flat’ or one that blew out shadows, highlights or colours. Some cameras less so, if they have good/intelligent processing, but never spot on, since the camera does not know your creative intent.
Can you suggest some of the tools with automatic jpeg export, after applying some processing? Ideally on Linux and not involving a great deal of sophistication. I tried to convert a sample RAW file with ffmpeg, but got an off color, low light image. I’m sure that’s something to do with the settings.
I’m sold on the better archiving opportunity. I just do photos of my own, I’m not involved in it professionally, but it still appeals to me.
Doable but subject to diminishing returns, possibly close to zero in your case. In camera raw development to jpeg has power and time constraints, yes, but it’s also a key workflow with 25+ years’ intensive optimization at this point. So the main benefit of retaining raw and doing off camera processing’s usually that you can make somewhat different development choices with a UX that’s less hassle to use than camera buttons.
However, results from reprocessing jpegs are often quite similar to what reprocessing raw offers, frequently to the point where anybody who’s not obsessive-compulsive about comparing the two developments side by side won’t notice or care. For general photography stuff it’s my experience if you need to go back to raw for more than a couple percent of the images you’re keeping it’s very likely a more efficient use of time to get things right in camera.
Main exception I’m aware of is high ISO composures where processing power’s applied to compensate for diminished SnR. That can be important to full resolution image delivery but, for posting online at 1-2 MP or print to .pdf sized for download, usually it barely matters. And the dynamic range off the sensor’s less than what jpeg can handle. So it’s actually not really about raw, people just talk about it like it is.
This isn’t to say jpeg artifacts aren’t a thing but, if they were a big deal outside of enthusiast photography forums, presumably there’d be more of a SooC migration to HEIC or WebP.
My experience is there’s generally little time or interest in going back and reprocessing. If you get into reprocessing and becomes a hobby then it’s more of a thing, as it is if you can get good business yield out of, er, remastering key images. But, realistically, most images run SooC and never get adjusted. Ones that do go through out of camera raw development are typically run through presets and never see individualized processing.
Storage is cheap but, for any substantial number of images, the time and money overhead to using raw still gets substantial. With typical reprocessing rates there’s not likely to be much practical difference between 100%, 10%, or even 1% raw retention. For many of enthusiast photographers it’s more enjoyable to go find another similar image than edit an existing one anyways.
So there’s a lot of ways to go here. Personally I don’t bother with phone raws and, while I leave raw enabled with ILCs unless burst speed’s an issue, mostly I use SooCs as is or with slight adjustments where raw makes basically no difference. I pull raws for the uncommon to rare images I come up with where SooC limitations are significant, outstanding images that might actually merit reprocessing, and just in case for stuff that’s notable and hard to reproduce.
Me neither. They’ve been stable for quite a while and the differences are usually tiny.
Agree but I’d like to clarify the phrasing here. A decent jpeg development retains the 7-8 most significant bits of the sensor’s maybe 12 bits resolution. Dropping the 4-5 least significant bits, max, is typically a negligible loss. Like if something’s about middle grey you might have to take the 0.3% worst case error of quantizing to 2048 instead of going with 2055 (give or take a scaling factor depending on the number of bits per channel).
That’s not normally much of an issue. Usually where I hit grief is when needing major contrast stretches to document details in snow under flat light. Which also looks bad coming from raw, just not quite as awful.
Probably. Raws are mostly manufacturer proprietary formats, though, and while DNG is open Adobe still holds the rights. So I wouldn’t sign up entirely for a 30 year preservation span without some planning around digital obsolescence.
Pretty much anything that does raw does batch conversion under configurable workflows. Darktable and RawTherapee are common choices.
As @lemma said, RawTherapee and Darktable are good options on Linux. I have not used them seriously for a couple of years though.
Photo editing is the main reason I still have a Windows VM. Linux still struggles with color management and while Darktable/RawTherapee (I believe they use the same convertor under the hood) yield great results there are some caveats. User interface is one of them, but also lack of some features like lens correction, profiles for your camera, etc.
I get pretty good results with CaptureOne’s automatic options most of the time. I’ll usually use them as a baseline and take it from there. But if you don’t want to spend much time you can batch import everything and apply auto corrections, then batch output to jpeg and in my experience get better results than SooC. Mind though I don’t have any newer camera than 2018ish, nor did I spend much time setting up jpeg picture profiles in camera. With a newer Fuji (which seem to be known for good SooC results) YMMV.
That really depends on the scene. I did some sundown pictures at the beach last summer with huge dynamic range (think sun at the horizon and long shadows of objects in the shot). If you have an APS-C or full frame camera with good dynamic range (and you exposed well!) you get to play with the dynamic range to get it to your liking. Perhaps my camera is too old (sony a7rii) but the jpegs will rarely pick the black point/white point and range as I want it.
Another scenario (though one that has gotten less common as cameras improved) is white balance correction. When your camera gets that wrong and your SooC jpeg comes out with a bad blue/green/… cast, good luck fixing that. Starting from RAW you can perfectly correct that.
If the camera somehow recognises what you want to do (portrait for example), yes, usually results will be pretty good. Probably a little flat but upping the contrast a bit is perfectly doable with a jpeg.
This is all just IMO, there’s a tradeoff of effort to results. I enjoy perfecting a handful pictures from a trip/outing to having a hundred nice enough ones. Depends on your goals as always.
I’m seeing that playing with files that are from a decade old sensor. Not huge but things improve slowly.
Adobe Lightroom get’s updates on new RAW formats faster than other tooling so I use a windows VM for it. I know Darkable is getting close but other options exist. I’m excited for Ansel or vkdt in the new future once they mature more. If they do, I may switch over to them and not need my windows VM but we are still a ways away.
You can play with the DR data on Protons to Photos
and see the values.
That’s really dependent on the scene in general. I’ve shot photos at night that still benefit from to the larger sensor size but are 5-6 stops so they could just fit into JPEG just fine. Arguably HEIC is the middle ground since JPEG IIRC is 8 bits and HEIC can do a bit more at 10-12 since most cameras, sans Medium format usually top out at 12 bits assuming you have the DR in the scene for it. For phones yeah I see little gains for RAW.
That said even IF the fidelity is similar, I still expose to the right to get more data to edit in post. Removing options like that then yes JPEG and RAW should be similar enough anyway for general usage outside of low light or related like stacking photos for astro and cameras are smart enough to slim down the excess data into a JPEG. I still don’t rely on it since editing is limited as an mentioned above, there are edge cases like color cast.
I honestly don’t see much value in phone raws since the sensor isn’t too big and likely the sensor itself is the bigger bottleneck. Emulating modern camera controls is nice but your ISO ranges are tiny for anything reasonable and the only gain is not going the AI today and doing it later… I do know from testing that most of the magic nowadays is just better AI algorithms or HW to do it but for phones I prefer JPEGs since I use them as is and don’t care after.
I don’t trust DNG long term and always recommend keeping the original RAW files as most tooling is expected to work on the RAW file but not necessarily the DNG.
The awkward middle ground is that you CAN convert an image into DNG AND also store a copy of the RAW with it. After that though you files are likely 2x as big.
FWIW I’ve never encountered difficulty removing color casts from ILC images in 8-bit formats. From what I can tell it’s mostly people are used to finding the adjustments as part of raw conversion rather than with, say, GIMP’s color temperature controls or channel curves. Been like a decade since I used Photoshop but even then its auto click on something that should be white or grey was pretty decent.
Where I have sometimes hit problems is with phone jpegs where the sensor’s underlying accuracy is poor and then the phone hype engine’s put so much on top of that it’s not fully recoverable. But, eh, if it’s anything that needs near perfect correction I’ll use an ILC.
Not sure about other editors as GIMP(+G’MIC) with occasional Darktable’s long met my needs.
Not something I’ve hit but then I’m too poor to afford Sony. Early Fuji firmware needed constant jockeying of the high and low turn curves, which got old (along with the crashes and lockups), and my experience with low end Canon around that time was the AWB would also often go off. Rather than bother with ETTR I usually just use Av and change exposure compensation to get close to what I want.
Before about 10 years ago I found there was more need to go to raw for the high dynamic range scenes being mentioned. Since then some of the SooC processing, like Panasonic iDynamic, has been outperforming what I can get from Darktable, GIMP, G’MIC, and RawTherapee at times.
Pretty much how I look at it too. There’s enough niche cases maybe it’s worth having OpenCamera or similar installed just in case if the default camera app doesn’t have a raw switch. But, yeah, probably not.
Yeah, might as well just convert to 16 bit .tif at that point. There’s enough open stacks with Nikon, Canon, and Sony raw support I think the risks are pretty low. That’s probably also true of Fuji, Pentax, Panasonic, and Olympus. But it’d still be not great to find out after 25 years a bunch of the images were laid down with a quirk that dropped out of support 10 years earlier because nobody was processing anything from that firmware version anymore.
A compromise I’ve used a lot is keeping raw+sooc. What practical experience of the past 20 years has shown is the jpegs are rarely revisited and the raws’ retention value’s next to zero. That’s with 90-95+% of images not going into archival storage.
Early Sonys like the A6000 were good enough for AWB but you can occasionally get one that’s a bit off but correctable. The later iterations are fine and improve the weakness back then, which was and still is low-light AF.
The main issue with Fuji is the different X-Trans algorithm over Bayes used that Lightroom, didn’t like early on. The sad part from what I’ve seen is there it’s all smoke and mirrors and trades one spec for another. Their Medium Format does NOT have X-Trans and cheaper APS-C cameras do not so that should tell you how well that is going.
Raws usually have a JPEG previews as well and most of the time, I just edit and store the exported JPEG at 100% size to get WHAT I would have wanted to keep.
Personally for me, I still keep RAWs as I do edit them. Sometimes image stitching algorithms improve so the stack of 9 RAWs get used again. The other thing for me is that I tag a lot of images and have geo information on them so sometimes it’s mainly the metadata I care for with the tags. Rarely I do notice an image I could retouch (I use some as desktop backgrounds so I will eventually see all of my outputted images) and revisit that way as well. That said I know I’m am exception to the rule but my 2 cents.
Yep. Cameras I have don’t support putting large+fine jpeg in the raw, though, hence the separate storage. Which has also been convenient on Windows, at least, as it’s pretty bad at looking inside of raws for image browsing.
Yeah, never really understood why people got so into the hype there. Like if it’s 40 MP APS-C it’s a zero sum allocation of 40 MP no matter what you do. Putting a few more of them on green necessarily means somewhat fewer red and blue samples and corresponding minor tradeoffs in information capture. Seems obvious, though I guess not so obvious as to prevent effective marketing.
I like that Fuji’s been willing to try different things. Also found Silkypix a nicely intuitive rethinking of the usual UX rather than brain bending the way a lot of people seem to. But neither of those is revolutionary and the firmware reliability I needed just wasn’t happening. Some of the lack of attention to mechanical detail was fairly problematic too. Hopefully it’s better now.
I used Xnview on Windows as a free way to view raws. There’s also Fast Raw Viewer that costs money but can be worth it depending on how often you do/use it.
The only way to get around it is by pixel shift in Sony or related where you move the camera sensor exactly 1 pixel so you can properly add up the 4 values per pixel without some Bayes nearest neighbor interpretation BUT it comes with the sacrifice of taking 4 shots in a row with no movement in the subject/background which may not always work.
Does Silkypix support hierarchical keywords and export them in XMP sidecar files? I’m trying to look for other supported tools but my camera, on release, didn’t have my cmaera for at least a year or two. I’m ok trying other workflow if it matches what I value of the most, tagging images via hierarchical keyword and searching it back up. I use those a lot when searching images in general, among other things. From what I see Silkypix isn’t a Digital Asset Manager (DAM) and solely an editor?
Yeah, super resolution’s been around for a while. I think Olympus put an implementation of it in a consumer camera first, Panasonic not much later, followed by Fuji, Nikon, Canon, Pentax, and Sony in roughly that order? Pixel shift’s pretty limited compared to microscopy and satellite methods but it’s also at a much lower price point with different user demands.
Stitching and downsizing also both address sampling constraints. Don’t think they motivate enthusiasts to upgrade bodies nearly as effectively as pixel shift, though. Focus stacking often offers similar properties as a side effect as well.
Realistically, most image delivery’s 1-2 MP so it only takes 4-8 MP Bayer to sample RGB within each output pixel. And it’s not that often more than 8 MP’s really needed, so single frame from most current ILC sensors is usually plenty fine. Honestly, past 16 MP APS-C I stopped caring and most of the images I gather are 8 or 12. I also work with 2+ GP image sets most days so it’s not like I’m unaware of the value of throwing MP at things. But diminishing returns diminish and use cases get increasingly niche.
Correct.
FWIW, so far I haven’t encountered a DAM which does enough more than intelligent file and directory naming to seem a worthwhile alternative to ls or Windows search for basic purposes. If it’s a mildly busy year I’ll log 100 000+ images into SQL for data analytics in R or whatever. But I’m just doing small scale stuff that’s basically side projects. Many of the folks I work with are in the tens of millions. DAMs aren’t built for that either.
So I’m just not in the DAM user demographic. Also doing data pretty much all day at work makes meticulously cataloging personal images just more work.
Canon and Nikon are about a year ago and Sony did there earlier albeit a more limited format initially out of the gate. The order is JVC (2007), Hasselblad (2007), Oly (2013), Pentax (2015?), Panosonic (2016?) , Sony (2017), Fuji MF (2021), Fuji APS-C (2022-2023) and then finally Nikon and Canon, The latter I don’t follow as much but googling says they exist in their recent mirrorless cameras.
The u4/3 cameras can do theirs in body so at least you can verify if it fails but it can work for some landscape shots but wind will kill it so yes it is very limited to macro/studio shots.
I mainly see the larger MP counts for printing that I plan to do with a collage of my work over a decade or so when I get there. I’m very happy with 24 MP for APS-C for a long while. The main advantage I’d argue of say 40-50 MP is like 8k video. You can use it to crop a lot in to get what you wanted, due to a lack of lens, or super sample it down a lot to get to your final goal with more fidelity. It would be nicer if the larger cameras could do that natively (while keeping the option of larger MP so a switch in software) so you get a 12 MP image with more fidelity than a 12MP shot but one can hope.
Also note that some modern cameras that are low MP like the a7sIII at 12MP is actually a 48MP shot down sampled 4:1 to get around any bayes issue but it is physically wired that way so no way to get back the 48MP. This leads to decrease in the noise floor and can lead to interesting case like seeing shooting stars at 100k ISO just fine without any editing so we’ve gotten quite a long ways to improvements over the years.
I don’t know what the solution is at 1 million or more shots. I use lightroom a lot for working with the metadata and some Python scripts to do simple aggregation over a year to see my numbers. Arguably the data could be rebuilt in some external DB relative to LR but I think you could just pull the catalog (or all the XMP files) to do similar queries. Likely a DB would be it but I haven’t looked since I haven’t had a need of it yet or perhaps ever.
We mostly use SQLite with automated metadata extraction and basic tagging plus Arrow Feather for flat files. There’s efforts to apply AI but the accuracy’s not there and isn’t likely to arrive in the foreseeable future. Review’s most at about 5 fps, so bringing in 10 M images/year’s about 14 work weeks. Not too bad if spread across a small team and across the year.
Somebody likely has a project that’s headed over 100 M images but I haven’t heard about it happening yet.
The intelligence part is just marketing hype. Machine learning’s fancy pattern matching is useful at times but the less constrained the task the more often it’ll be wrong and the greater the likelihood of glue on pizza and eating rocks fails. A couple of the many things my work time’s been split across in the past year is training image classifiers on what amounts to a yes-no question and a yes-no-irrelevant question.
For the yes-no one an unsupervised classifier I threw together in a morning runs over 2 GP in five minutes and is ~95% accurate. The machine learning takes hours to days to train, runs overnight, and is ~97% accurate. Look at any 100 x 100 pixel output cell and probably you’ll see an immediately obvious error or two. It’s 80+ hours’ labor per chunk of training data generated though, of which there are potentially hundreds, so having to manually correct “only” 3% instead of 5% is worth it.
The yes-no-irrelevant one’s not an LLM, so doesn’t hallucinate, but will happily overfit breakdowns in feature selection and generate wildly incorrect output that looks it’s tripping on LSD. Or maybe shrooms. I’m not sure. It’s hard to tell. I’ve established a lot of approaches don’t work, or don’t work very well, and have found some, er, care and feeding practices that keep it off drugs. But I’m increasingly skeptical more than 80-90% accuracy is possible. The alternative’s drawing like 10 M polygons by hand, however, which is an impossible amount of labor.
El Reg recently ran an opinion piece expanding NPU as needless pricey upsell and, I think, accurately referring to them as solutions in search of a problem. We’ll take 2 M wrong polygons to get 8 M good ones because the alternative’s having just a couple thousand. But when not backed up against a wall like that you’re looking for something better.