We asked camera companies why their RAW formats are all different and confusing
248 comments
·April 4, 2025Scaevolus
auxym
It took a long time for Canon CR3 raw format to be supported by darktable because, although the format itself had been reverse engineered, there was a fear from the developers that it was covered by a patent and that they risked a lawsuit by integrating it in DT. IIRC, they had attempted to contact Cabon legal to obtain some sort of waiver, without success.
I'm fact I'm not sure how that saga ended and CR3 support was finally added a few years after the release of the Canon mirrorless cameras that output CR3.
buildbot
I think that might be why a lot of camera makers don't care to use DNG - it's easier to make their own format and easy enough for others to reverse engineer it.
One thing that open source libraries do tend to miss is that very important extra metadata - for example, Phase One IIQ files have an embedded sensor profile or full on black frame that is not yet encoded into the raw data like it typically is for a NEF or DNG from many cameras. It does seem rawspeed handles this from a quick scan of the code.
It can get more tricky - Sinar digital backs have an extra dark frame file (and flat frame!) that is not part of the RAW files, and that is not handled by any open source library to my knowledge - though I did write a basic converter myself to handle it: https://github.com/mgolub2/iatodng_rs
I'm not sure how DNG would be able to handle having both a dark and flat frame without resorting to applying them to the raw data and saving only the processed (still unbayered) data.
Aaargh20318
> One thing that open source libraries do tend to miss is that very important extra metadata - for example, Phase One IIQ files have an embedded sensor profile or full on black frame that is not yet encoded into the raw data like it typically is for a NEF or DNG from many cameras.
In astronomy/astrophotography the FITS format[1] is commonly used, which supports all these things and is, as the name suggests, extremely flexible. I wonder why it never caught on in regular photography.
buildbot
Oh interesting! This seems like it would be a good fit ;)
Especially for really old setups that had RGB color wheels and multiple exposures, exactly like a multispectral astro image might. Phase one also has a multispectral capture system for cultural heritage, which just shoots individual IIQs to my knowledge… It would work great too for multiple pixel shift shots.
Possibly, the engineers just didn’t know about it when they were asked to write the firmware? It’s funny, I think most RAW formats are just weird TIFFs to some degree, so why not use this instead.
zokier
Can't you just throw such frames into additional IFDs or SubIFDs?
buildbot
Maybe? I’m not familiar enough with DNG to say - possibly that wasn’t a thing when Phase One first started using IIQ? I doubt it was around when Sinar was - in fact the last two (esprit 65 & S30|45 ) Sinar backs do use DNG as an option!
butlike
But can I see the difference in that applied metadata?
rickdeckard
> Cameras absolutely could emit DNG instead, but that would require more development friction: coordination (with Adobe), [..]
Technically speaking, implementing DNG would be another development activity on top of a RAW export, because RAW also has a purpose in development and tuning of the camera and its firmware.
It is supposed to be raw data from the sensor with some additional metrics streamed in, just sufficiently standardized to be used in the camera-vendors' toolchain for development.
It just "happens" to be also available to select for the end-user after product-launch. Supporting DNG would mean adding an extra feature and then hiding the RAW-option again.
I can imagine it's hard to make this a priority in a project plan, since most of the objectives are already achieved by saving in RAW
7bit
First of all, it does not "just happen" to be selectable. RAW contains information that is not available in a JPG or PNG , but which is crucial to a lot of serious photographers.
Second, the native raw images do include a ton of adjustments in brightness, contrast and color correction. All of which gets lost when you open the image file with apps provided from other companies than the camera vendor. Eg. open a Nikon-raw in NC Software and then in Lightroom. Big difference. Adobe has some profiles that get near the original result, but the Nikon raw standards often are better.
So DNG would absolutely be an advantage because then at least these color corrections could natively be implemented and not get lost in the process.
rickdeckard
Noone is disputing the advantage of RAW. I tried to provide the view from a pure development perspective, looking at a feature backlog.
It "just happens" to be selectable because it is a byproduct of the internal development: The existing RAW format is used internally during development and tuning of the product, and is implemented to work with vendor-internal processes and tools.
Supporting DNG would require a SEPARATE development, and it would still not replace a proprietary RAW-format in the internal toolchain.
(because the DNG patent-license comes with rights for Adobe as well as an option to revoke the license)
null
emkoemko
most people who shoot RAW don't care for the in camera picture adjustments so don't care if RAW shows up looking what it did in the camera because we apply our own edits anyways, if we need something like that we shot jpeg
redeeman
just encoding to DNG wouldnt do that. nikons software has its own profiles and stuff that it applies, and they would need to publish how that works. But that is generic, you could(nikon permitting) apply their processing to a photo taken by a canon. it has nothing to do specifically with the NEF format
Narretz
> It just "happens" to be also available to select for the end-user after product-launch
RAW (any format) is an essential requirement for many photographers. You just can't get the same results out of a jpeg.
rickdeckard
None of this is disputed (or relevant) in this conversation
naasking
> It is supposed to be raw data from the sensor with some additional metrics streamed in, just sufficiently standardized to be used in the camera-vendors' toolchain for development.
This is what I was thinking, that there are potentially so many RAW formats because there are so many sensors with potentially different output data. There should be a way to standardize this though.
rickdeckard
Yeah, but it's not standardised because its output is so close to "bare metal", it's wrapped into a standardised format a few steps later when a JPG/HEIC/... is created.
Supporting DNG means that those few steps later it should be standardised into ANOTHER RAW-equivalent. A format which happens to be patented and comes with a license and legal implications.
Among them the right for Adobe to every method you used to make this conversion from your proprietary bare-metal sensor-data. This is not trivial, because if you're a vendor working on sensor-tech you wouldn't want to be required to share all your processing with Adobe for free...
seba_dos1
> It is supposed to be raw data from the sensor with some additional metrics streamed in
...and what do you think DNG is?
rickdeckard
A patented format where Adobe standardized the exact syntax for each parameter, with mandatory and optional elements to be compliant, and (!) a patent license with some non-trivial implications which is also only valid if the implementation is compliant.
In a development environment, this format competes with an already-implemented proprietary RAW-format which already works and can be improved upon without involvement of a legal department or 3rd party.
bobmcnamara
A file format containing a subset of the image sensor data needed for tuning an image sensor. It's user focused rather than camera developer focused.
bufferoverflow
> Technically speaking, implementing DNG would be another development activity on top of a RAW export,
What are you talking about? Canon could implement DNG instead of CR3. It's not that hard. Both of these formats are referred to as "RAW".
rickdeckard
Just as I wrote. CR3 is used by Canon also during development and tuning of their sensors and cameras.
DNG would not replace CR3, because CR3 would still be needed before launch, and Canon has no incentive to change their entire internal toolchain to comply to Adobes DNG specification.
Especially not because the DNG format is patented and allows Adobe to revoke the license in case of dispute...
redeeman
not really, RAW is NOT just a raw sensor dump straight from the hw into a file.
its a full fledged format, that contains the extensive metadata already in the exif formats including vendor blocks etc, and then its the sensor readout, which is relatively similar between nearly all sensors, theres certainly not many types, considering you can express the bayer pattern. This can all be expressed in DNG, and would NOT need to be an "extra" on top of "raw".
and indeed, some camera vendors do in fact do this.
dllu
Fujifilm lossy compressed raw still isn't supported after many years [1].
[1] https://github.com/darktable-org/rawspeed/issues/366
And in my experience there has been lots of bugs with Fujifilm raws in darktable:
[2] https://github.com/darktable-org/rawspeed/issues/354
[3] https://github.com/darktable-org/darktable/issues/18073
However, Fujifilm lossless compressed raw actually does a decent job keeping the file sizes down (about 50% to 60% the file size of uncompressed) while maintaining decent write speed during burst shooting.
zahlman
It's really strange to me that a lossy compressed format could be called "raw". Does that just mean that it hasn't been e.g. gamma-corrected before the compression was applied? (Is it even a good idea to do lossy compression before such correction?)
4ad
All raw means is scene-referred data. The idea that somehow raw means "raw" data from the sensor is an often repeated idea, but unfortunately is completely nonsense. Modern sensors do on-chip noise reduction, they can be programmed to give data in all kind of formats and with different processing done to it. The same sensor used in different cameras can have different ISO. The same sensor used in different cameras can produce different RAW files even at the same ISO. Not just in the sense of a different file format, in the sense of different data in the file, from the exact same sensor, but programmed differently.
Syzygies
When my father bought his first digital camera, he insisted on raw format access.
Inexplicably I didn't understand at the time why he (Bryce Bayer) wanted this. He was modest about his work.
I do now!
dx4100
What an awesome dad! Lived during the golden age of photography and retired before its demise.
weinzierl
I always thought camera RAW formats were optimize continuous shooting rates. About being able to linearly write an image as fast as possible.
I don't know the details of DNG but even the slightest complication could be a no-go for some manufacturers.
Zak
The main reason people shoot raw is to have more creative control over the final product.
A simple example is white balance. The sensor doesn't know anything about it, but typical postprocessing makes both a 2700K incandescent and a 5700K strobe look white. A photographer might prefer to make the incandescent lights look more yellow. There's a white balance setting in the camera to do that when taking the picture, but it's a lot easier to get it perfect later in front of a large color-calibrated display than in the field.
Another example is dealing with a scene containing a lot of dynamic range, such as direct sunlight and dark shadows. The camera's sensor can capture a greater range of brightness than a computer screen can display or a printer can represent, so a photographer might prefer to delay decisions about what's dark grey with some details and what's clipped to black.
grandempire
?? This was not asked.
harrall
Everything you said is supported by regular image formats. You can adjust white balance of any photo and you think image formats are only limited to 16-bit and sRGB?
That’s not why we use RAW. It’s partly because (1) if you used Adobe RGB or Rec. 709 on a JPEG, a lot of people would screw it up, (2) you get a little extra raw data from the pre-filtering of Bayer, X-Trans, etc. data, (3) it’s less development work for camera manufacturers, and (4) partly historical.
tmoravec
The bottleneck is usually in SD card write speeds, however. Sport photographers often skip raw and only use JPG because the files are smaller and as a result, one can take more photos in one burst.
tomatocracy
For raw at high frame rates, high end cameras don't use SD cards but things like CFexpress which absolutely can keep up (and there are also various compressed RAW formats these days which apply a degree of lossy compression to reduce file size).
As I understand it, the reason some professional sports photographers don't shoot RAW (or it's less important) is more because they are in an environment where publishing quickly is important, so upload speeds matter and there isn't really much time to postprocess.
FireBeyond
Canon’s “sport professional” camera has lower resolution than the “second tier” cameras. It has a higher frame rate and CFExpress and SDXC2 so bandwidth isn’t an issue. Last I checked you could burst 40 or 50 frames (at 20ish fps) before filling the internal buffer.
m000
I believe this might have been the case in the past, where (a) sensor resolutions were lower - so the raw images less bulky, (b) camera CPUs were slower - so you would like to take them out of the equation.
These days, the bottleneck for achieving continuous shooting rate is probably writting to the sd card (which is the standard for the consumer/pro-sumer models).
octacat
It is always written into a memory buffer first, which could be like 256 megabytes... it tooks time to fill it up, once it is filled, memory card speed becomes a bottleneck. So, actually, writing only jpegs would trigger the slowdown later, so you could take more frames before the buffer fills up
gbin
This was my guess too, get the raw bayer data from the sensor in one go + some metadata. Then as the sensors and cameras evolve they are just accumulating different formats?
donatzsky
DNG is a TIFF file, just like most proprietary raw formats.
actionfromafar
The contents are simple. How to interpret the contents, is not simple. That is why you see internet advice advocating for keeping old raw files around, because Lightroom and Photoshop sometimes gets updates which can cram out better results from old raw files.
(Edit: I mean, if you want to get a basic debayered RGB image from a raw, that's not too hard. But if you want to cram out the most, there are a lot of devils in a lot of details. Things like estimating how many green pixels are not actually green, but light-spill from what should have been red pixels is just the beginning.)
mxfh
Yet that's processing level stuff, not format stuff. Even unlikely that the manufacturer made the best possible result from the sensor input as is.
sandofsky
> Cameras absolutely could emit DNG instead, but that would require more development friction: coordination (with Adobe), potentially a language barrier, and potentially making it harder to do experimental features.
I think this is being too generous.
DNG is just an offshoot of TIFF. Having written a basic DNG parser having never read up on TIFFs before, it really isn’t that hard.
As far as experimental features, there’s room in the spec for injecting your own stuff, similar to MakerNote in EXIF if I recall.
If you are planning to do experimental stuff, I’d say what Apple pulled off with ProRAW is the most innovative thing that a camera manufacturer has done in forever. They worked with Adobe to get it into the spec. All of these camera manufacturers have similar working relationships with Adobe, so there’s really no excuse. And if you can’t wait that long, again, MakerNote it.
In my opinion, custom RAW formats are a case study in “Not Invented Here” syndrome.
ChrisMarshallNY
Raw decoding is not as simple as you might think.
It’s the best place to add “signature steps.” Things like noise reduction, chromatic aberration correction, and one-step HDR processing.
I used to work for a camera manufacturer, and our Raw decoder was an extremely intense pipeline step. It was treated as one of the biggest secrets in the company.
Third-party deinterlacers could not exactly match ours, although they could get very good results.
_ph_
Well, it is obvious that between a RAW file and the final image there are a lot of complex processing steps. But that is independent of the file format used. DNG isn't so much different, just documented. And while the manufacturers converter might give the best results, the photographers rather use the image processing programs from Adobe or their competition which use their own RAW converters anyway.
ChrisMarshallNY
Yeah, they could do it with DNG (I suppose), but they don't really have any reason to do so (in their minds). Personally, I like open stuff, but they did not share my mindset, and I respected their posture.
_ph_
If a camera company sells me a camera, I consider it a definite disadvantage, if I cannot open the Raw files until the software companies have updated their products. This is also a great way of forcing customers into the subscription models like Adobe offers. So as a customer, I do criticize that they don't support more open formats.
starky
But this is talking about proprietary RAW image formats, which should be the data from the sensor with minimal processing. The entire point of RAW images is that you are skipping the majority of the ISP and applying those blocks in the processing software. Even the de-mosiacing step is done in the processor. There is really no reason why this is proprietary. This doesn't stop the camera company from applying their proprietary processing on the JPEG output that utilizes the full ISP.
ChrisMarshallNY
Not really.
If you claim to support a particular format, then you're responsible for supporting that format, and there's no reason why a company would do that, if they have no intentions of supporting anyone other than themselves from accessing the data.
"Not supporting" != "Not allowing"
They may not be thrilled by third parties reverse-engineering and accessing their proprietary formats, and can't necessarily stop them, but they are under no obligation to help them to do it, and they are free to change the rules, at their own whim.
Think of Apple, regularly borking cracking systems. It may not be deliberate. They may have just introduced some new data that cracked the crack, but there's no duty to support the crackers.
dllu
Anecdotally, using Darktable, I could never get as good of a demosaicing result as using the straight-out-of-camera JPEGs from my Fujifilm GFX 100S. In challenging scenarios such as fine diagonal lines, Darktable's algorithms such as LMMSE would add a lot of false colour to the image.
However, modern deep learning-based joint demosaicing and denoising algorithms handily outperform Darktable's classical algorithms.
hexo
Last thing I want my pictures touching is some deep learning based thingy.
koiueo
Can you share what company have you worked for?
ChrisMarshallNY
Not publicly. It’s not difficult to figure out, but I make it a point, not to post stuff that would show up in their search algorithms.
But it was a pretty major one, and I ran their host image pipeline software team.
[Edited to Add] It was one of the “no comment” companies. They won’t discuss their Raw format in detail, and neither will I, even though it has been many years, since I left that company, and it’s likely that my knowledge is dated.
Zak
> They won’t discuss their Raw format in detail
Can you share the reason for that?
It seems to me that long ago, camera companies thought they would charge money for their proprietary conversion software. It has been obvious for nearly as long that nobody is going to pay for it, and delayed compatibility with the software people actually want to use will only slow down sales of new models.
With that reasoning long-dead, is there some other competitive advantage they perceive to keeping details of the raw format secret?
koiueo
You've made it pretty clear, thank you.
That was my suspicion initially. In fact, when I read about mass DNG adoption, my first thought was "but how would it work for this company?" (admittedly I don't know much about DNG, but intuitively I had my doubts).
And then I saw your comment.
dkdbejwi383
It might be the non-mosaic one.
sandofsky
Raw decoding is an algorithm, not a container format. The issue is every is coming up with their own proprietary containers for identical data that just represents sensor readings.
ChrisMarshallNY
It's more than just a file format.
The issue is that companies want control of the demosaicing stage, and the container format is part of that strategy.
If a file format is a corporate proprietary one, then there's no expectation that they should provide services that do not directly benefit them, or that expose internal corporate trade secrets, in service to an open format.
If they have their own format, then they don't have to lose any sleep over stuff that doesn't interest or benefit them.
sandofsky
By definition, a RAW container contains sensor data, and nothing more. Are you saying that Adobe is using their proprietary algorithms to render proprietary RAW formats in Lightroom?
redeeman
pretty sure they would lose a lot of sleep if no third party application could open their raw
klysm
What does that have to do with storing the raw sensor values?
ChrisMarshallNY
See my comment below.
thatcks
One problem is that you cannot have a universal format that is both truly raw and doesn't embed camera specific information. Camera sensors from different companies (and different generations) don't have the same color (or if you prefer, spectral) responses with both their Bayer filter layer and the underlying physical sensor. If you have truly raw numbers, you need the specific spectral response information to interpret them; if you don't need spectral response information, you don't actually have truly raw numbers. People very much want raw numbers for various reasons, and also camera companies are not really enthused about disclosing the spectral response characteristics of their sensors (although people obviously reverse engineer them anyway).
sandofsky
> Camera sensors from different companies (and different generations) don't have the same color (or if you prefer, spectral) responses with both their Bayer filter layer and the underlying physical sensor
This is all accommodated for in the DNG spec. The camera manufacturers specify the necessary matrix transforms to get into the XYZ colorspace, along with a linearization table.
If they really think the spectral sensitivity is some valuable IP, they are delusional. It should take one Macbeth chart, a spreadsheet, and one afternoon to reverse engineer this stuff.
Given that third party libraries have figured this stuff out, seems they have failed while only making things more difficult for users.
fracus
What does RAW really mean then? Couldn't they simply redefine what RAW means to create a standard that can include proprietary technology? Like why not define it as including a spectral response?
thatcks
There is no 'RAW' format as such. In practice, 'RAW' is a jargon term for "camera specific format with basically raw sensor readings and various additional information". Typically the various RAW formats don't embed the spectral information, just a camera model identifier, because why waste space on stuff the camera makers already know and will put in their (usually maker specific) processing software.
(Eg Nikon's format is 'NEF', Canon's is 'CR3', and so on, named after the file extensions.)
I don't know if DNG can contain (optional) spectral response information, but camera makers were traditionally not enthused about sharing such information, or for that matter other information they put in their various raw formats. Nikon famously 'encrypted' some NEF information at one point (which was promptly broken by third party tools).
vr46
I did push for all my digital images to be DNG, and they are, up to around 2018, and two out of four cameras use it natively - Pentax, Leica - while the other two use their own formats - Canon, Fuji.
The reason I’m less fussy now is because the combination of edits, metadata and image data in a single file didn’t necessarily help me when I switched from Lightroom to Capture One. I would love to be able to update the files to use newer RAW processors and better IQ, but I lose the Lightroom edit information in C1. That makes sense as they do things differently. But I hoped that with DNG there was a universal format for handling edits.
My JPEGs remain the definitive version of the images but I would love to be able to recover all those original edits again in C1, or any other editing program.
lizknope
Every camera has a unique RAW format even cameras from the same company. The article briefly mentions this but doesn't go into that much detail. I've got at least 10 Nikon cameras going back to 2005 and every "NEF" Nikon RAW file is different so if you buy your camera on the first day it is released you have to wait for your software vendor to add support or shoot in JPEG format. There have been a few times when the RAW files are so similar that you can use a hex or EXIF editor and change the camera model EXIF field to an older supported camera and load the file. But in theory the RAW converter has been profiled for each specific camera using ICC color targets and stuff like that.
Zak
> But in theory the RAW converter has been profiled for each specific camera using ICC color targets and stuff like that.
In practice too, if consistent results are desired. The format being identical doesn't mean the values the sensor captures under the same conditions will be identical, so a color-calibrated workflow could produce wrong results.
It would be nice to have a setting for "treat camera Y like camera X (here there be dragons)" though. I've had to do something similar with the Lensfun database to get lens corrections working on Mk. II of a lens where Mk. I was supported, but a GUI would be nice. A prompt to guess the substitution automatically would be even nicer.
kookamamie
DSLRs have just dropped off the wagon a long time ago, when it comes to software and especially meaningful UX innovation.
As an anecdote, I have a Sony a7r and operating it via its mobile app is one of the worst user experiences I have had in a while.
Same goes to the surrounding ecosystem of software. E.g. Adobe's Lightroom is full of obsolete paradigms and weird usability choises.
wongarsu
Most hardware companies are just terrible at software in general. Camera makers are pretty average in that regard.
Usability of the camera hardware and software ecosystem is another matter. I think the common wisdom is that most paying users don't want beginner-friendly, they want powerful and familiar. So everything emulates the paradigms of what came before. DSLRs try to provide an interface that would be familiar to someone used to a 50 year old SLR camera, and Lightroom tries to emulate a physical darkroom. Being somewhat hostile to the uninitiated might even be seen as a feature.
numpad0
It's also like 4 digital dials. And you can leave most to Auto until you realize each specific dial enables something you desire. Sony tried "non-scary automagic" approach, and have instantly gone back to dials.
There's also Sigma BF if that's what you want; Sigma actually do pretty good job from perspective of minimalistic, idealistic, on-point, field usable UI, though the return of that effort just isn't worthwhile. I have the OG DP1, it feels natural as IntelliMouse PS/2. I've tried dp2 Quattro once and it felt natural as any serious right-handed trackballs. They scratch so many of camera nerds' itching points.
Most people just buys an A7M4 and an 24-70 Zeiss. And then they stupidly leave it all to auto and never touches the dials. And it puts smiles on people's faces 80% of times. And that's okay. No?
kookamamie
Yes, fully agreed. However, the way the companies currently approach this - catering for the ever-reducing niche, will end up killing the DLSRs over time. They just don't offer enough over phones, and the UX/SW being so crappy alienates the potential new userbase completely.
throwanem
> They just don't offer enough over phones
You can achieve maybe a quarter of the kinds of shots on a phone that an interchangeable-lens camera will let you make.
That's an extremely important quarter! For most people it covers everything they ever want a camera to do. But if you want to get into the other 75%, you're never going to be able to do it with the enormous constraints imposed by a phone camera's strict optical limits, arising from the tight physical constraints into which that camera has to fit.
daneel_w
Over the past 15-20 years I've used both Sonys, Canons and Nikons, and I absolutely feel that Nikon puts a lot more effort, with much better results, into the usability of their pro/prosumer cameras - and, really, even their $500-$1000 consumer range - both in terms of the on-display UI and the ergonomics and handling of the actual camera.
What always stood out most for me compared to Canon was Nikon's larger viewfinders, letting you commit to actual photography rather than being stuck with a feeling of peeping through a keyhole, and placement of buttons on the camera body allowing for maintained control of the most necessary functions (shutter speed, aperture and even ISO) without having to change your grip or move the camera away from your face.
throwanem
Nikon bodies are designed by photographers, and in the F-mount line, also by the same guy who did the Ferraris that made that brand's name.
Canon bodies are designed by engineers, who all had to prove they could palm a cinder block in order to get hired.
Sony bodies are designed by the cinder block.
stas2k
Only Nikons I own are 35mm film FM2 and F4. The bodies feel like tactile bliss. FM2 has a dry lubricated system with crazy titanium honeycombed etched shutter and F4 is the last pro DSLR they made with no menu system.
On the digital front I found Fuji X-Txx series to be like tiny Nikons in their usability with all common controls on dials.
kjkjadksj
I havent tried the mirrorless cameras but on dslr canon is great ux imo. Everything you need to adjust on the fly is easy. Its usually controlled with a dial that can change the parameter it adjusts with a modifier button. Saving you what might be yet another dial on like a fuji xt5.
But even then once youve metered a scene how often do you adjust iso on the fly? Hardly ever. Fixed iso, aperture priority, center dot focus and metering, off to the races.
Sharlin
Sony is famous for having the worst interfaces of all the big camera manufacturers.
Lightroom most likely has “obsolete paradigms” for the same reason Photoshop does: because professionals want to use what they know rather than what is fashionable. Reprogramming their muscle memory is not something people want to be doing. Anyway, I find Lightroom’s UI very nice to work with.
throwanem
Lightroom is very intuitive, once you've spent a few years learning how everything works.
Sharlin
I don't know, I think the learning curve is pretty gentle. Like all complex software, it may be difficult to master, but getting started felt easy enough as far as I remember.
colejohnson66
S̶o̶,̶ ̶i̶t̶'̶s̶ ̶n̶o̶t̶ ̶i̶n̶t̶u̶i̶t̶i̶v̶e̶?̶ ̶I̶f̶ ̶i̶t̶ ̶t̶a̶k̶e̶s̶ ̶y̶e̶a̶r̶s̶ ̶t̶o̶ ̶l̶e̶a̶r̶n̶,̶ ̶t̶h̶a̶t̶'̶s̶ ̶n̶o̶t̶ ̶"̶s̶i̶m̶p̶l̶e̶"̶.̶
Mashimo
Yes, same for my Sony A6000 and A6400. I just wanted to take some selfies and it's exhausting to use the remote app.
kookamamie
Yes, it's mind-bogglingly difficult and complicated.
to11mtm
At the time of release of the A6000, having a mobile app to take a picture (and not having to buy an adapter like some other brands) was cool enough that you could deal with the (at the time, relatively minor) jank.
Biggest thing is they never really improved the mobile apps... and in some cases IMO they got worse.
girvo
Fujifilm is no better haha, they're on their third (I think) mobile app this time for X-Series camera control, and it's still terrible.'
Amusingly, their Instax control app is actually pretty good!
neogodless
There are 8+ Instax apps made by Fujifilm in the app store. Which one is pretty good for controls?
girvo
"instax mini EVO" specifically, because thats the Instax I have these days :)
kjkjadksj
The one for my 2016 era fuji is crap. Camera remote. Usually the connection fails between my phone and the cameras own wifi network it connects to but this failure takes a good 2 minutes to happen. So many artificial software limits with this camera, some removed in newer versions. Why can’t this one tether though? It is literally a digital camera no?
Anyone know of any fujifilm firmware jailbreaks fwiw?
girvo
No jailbreaks/CFW as far as I'm aware sadly.
You might be able to use XApp instead, which is still crap but better than Camera Remote at least.
schobi
When building a camera, you decide once and then most parameters stay fixed. It would be trivial to just append 1000 bytes for a mostly fixed DNG header to each image.
But how do you test this? While the DNG specification is open source, the implementation was/is(?) not. Do I really need a copy of Photoshop to test if my files are good? How would I find good headers to put into my files? what values are even used in processing?
Maybe the situation has changed, but in the old days when I was building cameras there was only a closed-source Adobe library for working with DNGs. That scared me off.
goeiedaggoeie
Things like camera intrinsics and extrinsics are not fixed. 1000 bytes seems small to me given the amount of processing in modern cameras to create a raw image. I could easily imagine storing more information like focus point, other potential focus points with weights as part of the image for easier user on device editing.
Cadwhisker
For testing, there's the Adobe DNG SDK: https://helpx.adobe.com/camera-raw/digital-negative.html
You'll find the whole spec there, too. I think the source is also available somewhere.
seba_dos1
The camera app on my GNU/Linux phone stores DNGs with no troubles using FLOSS only.
gwbas1c
> If a manufacturer comes up with additional data that isn’t included in the DNG standard, the format is extensible enough that a camera manufacturer can throw it in there, anyway.
It sounds like DNG has so much variation that applications would still need to support different features from different manufacturers. I'm not sure it (DNG) will really solve interoperability problems. This issue smells like someone is accidentally playing politics without realizing it.
Kind of reminds me of the interoperability fallacy with XML. Just because my application and your application use XML, it doesn't mean that our applications are interoperable.
I suspect that a better approach would be a "RAW lite" format that supports a very narrow set of very common features; but otherwise let camera manufacturers keep their RAW files as they see fit.
AntonyGarand
Seems like DNG does behave like the RAW lite format you've just described: Everything common would be stored within the base DNG file, while everything "advanced" / more specific to a camera would be stored in additional metadata properties, which do not need to be parsed to still be able to process the base image. You can add support for these metadata on a case-by-case basis without breaking the original format, so you're not stuck re-implementing your whole raw parsing when a new camera is released as the base subset of DNG would still work.
sandofsky
Hey. I’m the guy quoted.
RAW is ultimately about sensor readings. As a developer, you just want to get things from there into a linear, known color space (XYZ in the DNG spec). So from that perspective, interoperability isn’t the issue.
How you process that data is another matter. Handling a traditional bayer pattern vs a quad-bayer vs Fujifilm’s x-trans pattern obviously requires different algorithms, but that’s all moot given DNG is just a container.
yjftsjthsd-h
This isn't really my area, so I'm probably wrong... I'd always assumed that RAW files were, well, raw data straight off the sensor (or as close as possible)? In which case, you could standardize the container format, but I wouldn't think it was possible to have a standard format for the actual image data. Would appreciate if anyone could correct me (a quick skim of wikipedia didn't clear it up)
wmf
Most image sensors are quite similar (ignoring weirdos like X-Trans and Foveon) so they could use the same format and decoding algorithm. It's a 16-bit integer (padded out from 12 or 14 bits) for each pixel with a Bayer color filter. Maybe throw in some parameters like a suggested gamma curve.
ekianjo
Foveon has awful Foss support so far. Older foveon models also require an older version of windows to run the antiquited software to process raw pics, it's maddening.
buildbot
The algorithms for getting a useable image from a Foveon sensor are very non trivial from what I understand - the different layers don’t separate light perfectly into red, green, and blue bands, so there is some fancy cross layer processing you need to do.
buildbot
Typically they are not to my knowledge! Though I am also not an expert. Most camera makers apply a fixed sensor profile, and possibly a dark frame to remove noise before writing out the values to whatever file. Some of them may apply lens optimizations to correct distortion or vignetting as well.
mubou
On top of that, I hear the RAW format on some smartphones is saved after the phone does its fake-HDR and computational photography bullshit, so it's even further from "raw" with those cameras.
kalleboo
This is true for Apple's "ProRAW" that you get if you choose RAW in the iOS camera app. Third party camera apps like Photon can shoot actual RAW raw though, the hardware and OS APIs do support it.
tobyhinloopen
The corrections are just metadata, the RAW data is still there. This is true for both DNG and ARW (Sony). Dont know the other brands. The corrections can even look different based on what program you use to interpret them.
buildbot
I don’t think that’s true in general. As a sibling comments points out, this is not true for some DNGs - for example, the output of an iPhone is in DNG, but with many, many transforms already baked in. A DNG might even be debayered already.
GFX 100s II’s apply a transform to RAW data at iso 80, see: https://blog.kasson.com/gfx-100-ii/the-reason-for-the-gfz-10...
I don’t know much about ARW, but I do know that they offer a lossy compressed format - so it’s not just straight off the sensor integer values in that case either.
tobyhinloopen
It's all float value arrays with metadata in the end. Most camera sensors are pretty similar and follow common patterns.
DNGs have added benefits, like including compression (optional) (either lossy or lossless) and error correction bytes to prevent corruption (optional). Even if there's some concerns like unique features or performance, I'd still rather use DNGs without these features and with reduced performance.
I always archive my RAWs as lossy compressed DNGs with error correction and without thumbnails to save space and some added "safety".
schobi
Nitpicking correction: The sensors give you a fixed number of bytes per pixel, like 10 or 12 bits per pixel. This are unsigned integers, not floats.
Typically you want to pack them to avoid storing 30% of zeros. So often the bytes need unscrambling.
Any sometimes there is a dark offset: In a really dark area of an image, random noise around zero can also go negative a little. You don't want to clip that off, and you don't want to use signed integers. So there typically is a small offset.
null
null
kazinator
> Photo editing software needs to specifically support not just each manufacturer’s file type but also make changes for each new camera that shoots it
You mean, your proprietary, closed-source Photo-editing sofware?
Why can't the vendors of that shit just make a library that they all share ...
_ph_
The ironic part is, that basically all the closed-source photo-editing software (and of course all open-source) are just using the open source LibRaw. Any special features as color profiles comes on top of that. So yes, the camera manufacturers could just donate to LibRaw or just use DNG instead.
ksec
Interesting not a single mention yet. Some companies are considering using JPEGXL Lossless as RAW.
t0bia_s
Compressed RAF (Fujifilm, 24MP) ~20 MB
DNG (24MP) ~90 MB
It cost about 4 times more to store RAW files in DNG format.
coder543
I downloaded a sample RAF file from the internet. It was 16 megapixels, and 34MB in size. I used Adobe DNG Converter, and it created a file that was 25MB in size. It was actually smaller.
Claiming that DNG takes up 4x space doesn't align with any of my own experiences, and it didn't happen on the RAF file that I just tested.
hoherd
To test this, I downloaded a random RAF image from this gallery https://mirrorlesscomparison.com/galleries/fuji-xt2-sample-i...
$ /Applications/Adobe\ DNG\ Converter.app/Contents/MacOS/Adobe\ DNG\ Converter DSCF6001.RAF
SPL-LOG-1002: starting logger thread
*** GPU Warning: GPU3 disabled via cr_config at init time. ***
SPL-LOG-1003: terminating logger thread
SPL ~DefaultMemoryManagerImpl bytesAllocated = 0
$ ls -la DSC*
-rw-r--r-- 1 danielh staff 50377216 2025-04-07T10:59:30 DSCF6001.RAF
-rw-r--r-- 1 danielh staff 30747896 2025-04-07T11:00:13 DSCF6001.dng
4ad
He probably compares a mosaiced RAF with a debayered (linear) DNG. Just... don't do that. Use a mosaiced DNG. And certainly don't embed the RAF file. Plus with lossless JPEG-XL, the difference is trivial (under 5%):
On my own files:
edengate:1$ ls -l
total 163664
-rwx------@ 1 aram staff 40894672 Apr 4 15:25 DSCF1483.RAF
-rw-r--r--@ 1 aram staff 42894224 Apr 7 16:51 DSCF1483.dngt0bia_s
Lightroom cannot do that. I'm not sure if Iridient X-transformer have some options for this. I always ended up with massive files.
Also, I'm not confident to replace entire RAF collection with converted DNGs and delete originals.
4ad
No it doesn't. A DNG is just a container that can hold anything, including compressed data, just like the RAF.
Coincidentally, most proprietary RAW formats are just bastardized TIFFs, and DNG is also a TIFF derivative...
There is zero technical reason not to use DNG. Leica and Pentax use it just fine.
t0bia_s
Please explain how can I convert compressed RAF to DNG with same size.
immibis
It's a very common mistake in free software to not design a system end-to-end. Free software people will design some kind of generic container format and go "look! you can put anything in the container!", declare the job done, and then not write tools which actually do put anything in the container, or tools which can make use of anything in the container other than one specific thing.
(See: ActivityPub)
Ultimately, RAW formats aren't that complex, and camera firmware is mostly developed in countries that don't have strong open source software traditions.
Look at the decoders for each format that darktable supports here: https://github.com/darktable-org/rawspeed/tree/develop/src/l...
It's some binary parsing, reading metadata, maybe doing some decompression-- a thousand lines of C++ on average for each format. These aren't complex codecs like HEVC and only reach JPEG complexity by embedding them as thumbnails!
Cameras absolutely could emit DNG instead, but that would require more development friction: coordination (with Adobe), potentially a language barrier, and potentially making it harder to do experimental features.
Photographers rarely care, so it doesn't appreciably impact sales. Raw processing software packages have generally good support available soon after new cameras are released.