# DarkRoom camera base curves (FR-DEV-3e). # # --------------------------------------------------------------------------- # Adding a body is editing this file. It is not a code change. # --------------------------------------------------------------------------- # # The copy you are reading is compiled into the binary as a floor. At startup # `dr_decode::base_curve::load` also looks for `base_curves.yaml` in: # # 1. $DARKROOM_PROFILES/ (set it while you are tuning) # 2. $XDG_DATA_HOME/darkroom/profiles/ # or $HOME/.local/share/darkroom/profiles/ # # and uses the first one it finds *whose `version:` is higher than this one's*. # So: bump `version`, drop the file in that directory, restart. A body added # this afternoon renders correctly this afternoon, with no release and no # rebuild — which is what the requirement asks for, and what makes these # contributable under the GPL. # # The version check runs both ways on purpose. A file older than the built-in # copy is ignored with a log line, so upgrading DarkRoom cannot silently lose # curves to a pack somebody downloaded a year ago. # # --------------------------------------------------------------------------- # What the numbers mean # --------------------------------------------------------------------------- # # Five `[x, y]` control points on a monotone spline (Fritsch-Carlson, the same # one the tone curve widget draws). Both axes are **linear**: # # x scene-referred camera RGB after white balance, 1.0 = sensor saturation # y display-referred linear; the sRGB transfer function is applied later, # at the end of the shader, so do not pre-apply a gamma here # # The identity is y = x, and it is what an unrecognised body gets if `default:` # is removed. It is also the wrong answer for almost every photograph: linear # scene data has middle grey at about 13% and a camera JPEG puts it near 18%, # so an uncurved render is roughly half a stop dark through the midtones and # has no highlight rolloff at all. # # A curve that works has three parts, and it is worth naming them because they # are what you are actually tuning: # # the toe the first span, slope near or below 1. Deep shadows stay # deep. Lift it and blacks go milky; crush it and shadow # detail the sensor recorded disappears. # the midtones the middle spans, slope well above 1. This is the contrast # and the brightness people read as "the camera's look". # the shoulder the last span, slope well below 1. Highlights compress # toward white instead of arriving there and clipping. It is # the difference between a rolled-off sky and a white hole. # # Two invariants are enforced in code and tested, so a mistake here fails the # build rather than the photograph: x must strictly increase, y must not # decrease, and everything must lie inside the unit square. # # --------------------------------------------------------------------------- # Honesty about these values # --------------------------------------------------------------------------- # # These are hand-tuned shapes, not measurements. They encode what every camera # JPEG rendering has in common — the toe/midtone/shoulder structure above — # plus each maker's well-known house differences: Canon's gentler shoulder and # warmer-reading midtones, Nikon's slightly higher midtone contrast, Sony's # flatter and more conservative default, Fujifilm's markedly contrastier # Provia-derived rendering. # # FR-DEV-3e's acceptance criterion is subjective comparison against each body's # own JPEG, and meeting it properly needs a frame from that body in front of # you. Where that has not been done, the entry is still much closer to right # than the identity — which is the bar these have to clear, and do. version: 1 # The rendering for a body with no entry of its own. # # **Deliberately not the identity.** The failure this requirement exists to fix # is the flat render, and a conservative curve is far closer to right for every # body than no curve is for any of them. It is gentler than the per-body # entries below — a shallower midtone and an earlier, softer shoulder — because # it has to be safe on a sensor nobody has looked at, and the cost of being too # tame is a photograph that wants a little contrast rather than one that has # lost its highlights. default: points: - [0.00, 0.000] - [0.04, 0.043] - [0.13, 0.175] - [0.45, 0.690] - [1.00, 1.000] bodies: # Canon. A soft toe and a long, gradual shoulder — the reason Canon files # are described as forgiving in highlights and a little low in contrast # straight out of camera. - make: Canon model: EOS 6D points: - [0.00, 0.000] - [0.04, 0.045] - [0.13, 0.190] - [0.45, 0.720] - [1.00, 1.000] - make: Canon model: EOS R6 points: - [0.00, 0.000] - [0.04, 0.044] - [0.13, 0.195] - [0.45, 0.730] - [1.00, 1.000] # Nikon. A slightly deeper toe and more midtone slope than Canon, which is # the "punchier out of camera" difference people describe between the two. - make: Nikon model: Z 6 points: - [0.00, 0.000] - [0.04, 0.038] - [0.13, 0.200] - [0.46, 0.750] - [1.00, 1.000] - make: Nikon model: D750 points: - [0.00, 0.000] - [0.04, 0.039] - [0.13, 0.198] - [0.46, 0.745] - [1.00, 1.000] # Sony. The flattest default of the four, and intentionally so — Sony's own # rendering leaves more headroom than it uses, which is why Sony files are # the ones people describe as needing the most work. - make: Sony model: ILCE-7M3 points: - [0.00, 0.000] - [0.04, 0.048] - [0.13, 0.185] - [0.44, 0.700] - [1.00, 1.000] # Fujifilm. Provia, the default film simulation: a firm toe, the steepest # midtones here, and a hard shoulder. It is the most distinctive rendering of # the four and the one where a flat render looks most obviously wrong. # # This entry does *not* read the in-RAF film simulation tag — that is # FR-DEV-3f, and until it lands every Fujifilm file gets the Provia shape # whatever the camera was set to. - make: Fujifilm model: X-T3 points: - [0.00, 0.000] - [0.045, 0.040] - [0.14, 0.215] - [0.47, 0.775] - [1.00, 1.000]