←back to thread

361 points Tomte | 6 comments | | HN request time: 1.111s | source | bottom
Show context
Scaevolus ◴[] No.43584261[source]
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.

replies(12): >>43607682 #>>43608468 #>>43609020 #>>43609118 #>>43609169 #>>43609799 #>>43612739 #>>43612940 #>>43615274 #>>43615505 #>>43617505 #>>43624875 #
rickdeckard ◴[] No.43609118[source]
> 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

replies(6): >>43609335 #>>43609959 #>>43609969 #>>43612792 #>>43612984 #>>43619858 #
seba_dos1 ◴[] No.43609969[source]
> It is supposed to be raw data from the sensor with some additional metrics streamed in

...and what do you think DNG is?

replies(2): >>43611580 #>>43611925 #
1. bobmcnamara ◴[] No.43611925[source]
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.
replies(1): >>43612379 #
2. seba_dos1 ◴[] No.43612379[source]
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.

replies(2): >>43612611 #>>43621548 #
3. ◴[] No.43612611[source]
4. bobmcnamara ◴[] No.43621548[source]
Our proprietary format was a header followed by a raw sensor dump.

Despite this, people eventually used it for photographic purposes.

replies(1): >>43627827 #
5. seba_dos1 ◴[] No.43627827{3}[source]
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.
replies(1): >>43630835 #
6. bobmcnamara ◴[] No.43630835{4}[source]
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.