We asked camera companies why their RAW formats are all different and confusing

> 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

> 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.

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.

> It is supposed to be raw data from the sensor with some additional metrics streamed in

...and what do you think DNG is?

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.

None of this is disputed (or relevant) in this conversation

This is not correct. Both the subhead of the article and the DNG format's Wikipedia Page state that DNG is open and not subject to IP licensing.

While having two file formats to deal with in software development definitely "competes" with the simplicity of just having one, patents and licensing aren't the reason they're not choosing Adobe DNG.

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)

The fact that both your sources are NOT the actual DNG license text should be sufficient to humble yourself from "This is not correct" to at least a question.

--> Your information source is incomplete. Please refer to the license of DNG [0].

The patent rights are only granted:

1. When used to make compliant implementations to the specification,

2. Adobe has the right to license at no cost every method used to create this DNG from the manufacturer, and

3. Adobe reserves the right to revoke the rights "in the event that such licensee or its affiliates brings any patent action against Adobe or its affiliates related to the reading or writing of files that comply with the DNG Specification"

--

None of this is trivial to a large company.

First of all, it requires involvement of a legal department for clearance,

Second, you are in risk of violation of the patent as soon as you are not compliant to the specification,

Third, you may have to open every IP to Adobe at no charge which is required in order to create a DNG from your sensor (which can be a significant risk and burden if you develop your own sensor) and

Fourth, in case the aforementioned IP is repurposed by Adobe and you take legal action, your patent-license for DNG is revoked.

--

--> If you are a vendor with a working RAW implementation and all the necessary tools for it in place, it's hard to make a case on why you should go through all that just to implement another specification.

[0] https://helpx.adobe.com/camera-raw/digital-negative.html#dng

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.

None of this is terrifying and seems overblown. I read the patent grant you linked to. It makes sense that one would not grant the right to make incompatible versions. That would confuse the user. Also, the right of revocation only applies if the DNG implementor tries to sue Adobe. Why would they do that?

Occam's razor here suggests that the camera manufacturers' answers are correct, especially since they are all the same. DNG doesn't let them store what they want to and change it at will -- and this is true of any standardized file format and not true of any proprietary format.

In my personal opinion, considering a file format as something that is patentable is where you've (ie your country) has gone wrong here.

It doesn't seem to reward innovation, it seems to reward anti-competitive practices.

Neither DNG nor various vendor-specific raw formats are meant for tuning an image sensor. They can be used for that in some specific cases, but it's not what they are for. They're for taking photos and providing the user with less opinionated data so they can do the processing of their photos the way they want rather than rely on predefined processing pipeline implemented in the camera.

Despite the name, this is rarely a pure raw stream of data coming from the sensor. It's usually close enough for practical photographic purposes though.

What? Number two would make most companies run the other way. “Whatever you use to create a DNG, secret sauce or algorithm or processing from your sensor data, Adobe can license” - you act like it’s no big deal but it’s often the closely guarded color science or such things.

You can argue that maybe those things shouldn’t be considered trade secrets or whatever. But there’s just a bit more to it than that.

> None of this is terrifying and seems overblown. I read the patent grant [..]

Considering that you entered this discussion instantly claiming that others are wrong without having even read the license in question makes this conversation rather..."open-ended"

> Also, the right of revocation only applies if the DNG implementor tries to sue Adobe. Why would they do that?

As I wrote above, Adobe reserves the right to use every patent that happens to be used to create this DNG from your design at no cost, and will revoke your license if you disagree i.e. with what they do with it.

> Occam's razor here suggests [..]

Or, as I suggested, it's simply hard to make a case in favor of developing and maintaining DNG with all that burden if you anyway have to support RAW

> 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.

Also...

> granted by Adobe to individuals and organizations that desire to develop, market, and/or distribute hardware and software that reads and/or writes image files compliant with the DNG Specification.

If I use it for something it's not images because I want to create a DNG file that's a DNG file and a Gameboy ROM at the same time. Or if I'm a security researcher testing non compliant files. Or if I'm not a great developer or haven't had enough time to make my library perfectly compliant with the specification... Will I be sued for breaking the license?

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...

> 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".

I disagree. Bufferoverflow frames raw formats as something that's really only there for R&D purposes, and it's more or less just an afterthought that it's available to photographers. In reality, Narretz points out, getting access to the raw sensor data is a key feature to many photographers; it's an essential aspect of the product from a user perspective.

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

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...

The fatal scenario for a camera vendor would be to transition your customers to DNG over some years, then a dispute arises which causes Adobe to revoke your patent license, and suddenly all your past products are in violation of Adobe's DNG patent.

You not only have to remove DNG-support on those products, but due to warranty-law in many countries have to provide an equivalent feature to the customer (--> develop a converter application again, but this time for products you already closed development for years ago).

Alternative would be to settle with Adobe to spare the cost for all that. So Adobe has all the cards in this game.

Now: Why bother transitioning your customers to DNG...?

Since you disagree: where in this thread did anyone state the opposite of what you just wrote, who said that RAW is NOT a key feature to many photographers?

I have no knowledge of DNG, what I was suggesting is that someone should devise a some kind of extensible, self-describing format that can be used in place of RAW without losing any sensor data as with JPEG/HEIC/etc.

Ah I see.

Well, DNG ("Digital Negative") is such a format, defined and patented by Adobe, but with a license allowing free use under certain conditions.

The conditions are somewhat required to make sure that Adobe remains in control of the format, but at the same time they create a commitment and legal implications for anyone adopting it.

That's fair. It's certainly not "open source" in that way that term is usually used. I still think that's not the primary issue and that the manufacturers are being honest about their preference for proprietary formats. But I see that Adobe legal concerns hanging over their heads isn't an advantage, for sure.

> it seems to reward anti-competitive practices.

That is the intended purpose of a patent. From WIPO [1]:

> The patent owner has the exclusive right to prevent or stop others from commercially exploiting the patented invention for a limited period within the country or region in which the patent was granted. In other words, patent protection means that the invention cannot be commercially made, used, distributed, imported or sold by others without the patent owner's consent.

[1] https://www.wipo.int/en/web/patents

Here:

> 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.

Nothing here states that a RAW format is NOT a key feature to many photographers. This is a straw-man argument.

It says that it "just happens" to be available to customers and the main reason it exists is for R&D. That's what I disagree with.

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.

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

The whole post shapes the context, even the whole sentence helps already: 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.

--> Even if DNG-support would be adopted as a feature for the end-user, the proprietary RAW would still need to be maintained because it has a core-purpose during development of the product. The utilization AFTER that is the product-feature

None of this negates the value of RAW for photographers, this is completely beside the topic

That's not how I interpret it ¯\_(ツ)_/¯

Hence I, the person who wrote it (!), keeps clarifying the intended interpretation by (re)iterating that noone disputes the value of RAW for photographers.

It is up to you now to ingest new information and adjust your interpretation, a process I'm afraid I can't help any further with.

Good luck ¯\_(ツ)_/¯

Our proprietary format was a header followed by a raw sensor dump.

Despite this, people eventually used it for photographic purposes.

So is DNG in the implementation I've worked on (data as outputted by the sensor wrapped in a TIFF structure), but whether what the sensor outputs is actually "raw" can be debatable and is sensor- and configuration-dependent.

Absolutely true. Our sensors would dump their registers in the first few lines so at least you knew what settings were used for that frame.