Most active commenters
  • buildbot(4)
  • tobyhinloopen(4)

←back to thread

361 points Tomte | 18 comments | | HN request time: 0.434s | source | bottom
1. yjftsjthsd-h ◴[] No.43607646[source]
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)
replies(5): >>43607699 #>>43607915 #>>43607925 #>>43608218 #>>43609806 #
2. buildbot ◴[] No.43607699[source]
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.
replies(2): >>43607801 #>>43608231 #
3. mubou ◴[] No.43607801[source]
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.
replies(1): >>43618360 #
4. ◴[] No.43607915[source]
5. wmf ◴[] No.43607925[source]
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.
replies(1): >>43609726 #
6. tobyhinloopen ◴[] No.43608218[source]
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".

replies(1): >>43608353 #
7. tobyhinloopen ◴[] No.43608231[source]
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.
replies(1): >>43608269 #
8. buildbot ◴[] No.43608269{3}[source]
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.

replies(2): >>43608437 #>>43608497 #
9. schobi ◴[] No.43608353[source]
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.

10. tobyhinloopen ◴[] No.43608437{4}[source]
Okay true, but that's not the format's fault (:

The GFX 100s II thing is very interesting. Totally not what I would expect from such a "high end" camera.

11. spookie ◴[] No.43608497{4}[source]
damn, that is a quirk that would've led me pulling my hair out if I worked with those.
replies(1): >>43611364 #
12. ekianjo ◴[] No.43609726[source]
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.
replies(1): >>43612979 #
13. ◴[] No.43609806[source]
14. tobyhinloopen ◴[] No.43611364{5}[source]
At least it's only at ISO 80, where noise would be minimal anyway (: I rarely use noise reduction because I don't like the artificial cleanliness of the result.
15. buildbot ◴[] No.43612979{3}[source]
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.
replies(1): >>43641631 #
16. kalleboo ◴[] No.43618360{3}[source]
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.
17. ekianjo ◴[] No.43641631{4}[source]
interesting, where did you learn that from?
replies(1): >>43656305 #
18. buildbot ◴[] No.43656305{5}[source]
This paper has a bit about it, not very in depth though: https://www.imaging.org/common/uploaded%20files/pdfs/Papers/...