Those methods come from the world of non-realtime CG rendering though - running truly accurate simulations with the aberrations changing across the field on phone hardware at any decent speed is pretty challenging...

PBRT 3rd edition actually has a great section on the topic but it's one of the parts that wasn't implemented for the GPU (by the authors, anyway): https://pbr-book.org/3ed-2018/Camera_Models/Realistic_Camera...

As you suggest storage in linear 16-bit float is standard, the procedure for calibrating cameras to produce the SMPTE-specified colourspace is standard, the output transforms for various display types are standards, files have metadata to avoid double-transforming etc etc. It is complex but gives you a lot more confidence than idly wondering how the RGB triplets in a given JPG relate to the light that actually entered the camera in the first place...

At some point someone did tell me something that helped though: think of and describe what you're looking at using food terms instead of anatomy ones - talk about a blood fluid sim as being "too much like tomato juice not enough like gravy", textures in terms of mince/steak etc rather than human tissue types. I also labelled render passes like that, made conversations sound a lot less gross and more removed from reality, particularly to passers-by working on other shots...

Maybe this one from 2007: https://www-pequan.lip6.fr/~bereziat/cours/master/vision/pap...

I'd love to hear otherwise but I'm not aware of any commercial "machine learning" for post-production aside from the Nvidia Optix denoiser and one early beta of an image segmentation plugin.

It seems tough to come up with hard and fast rules for whether to mimic the linear physical processes, or work in a perceptual space more like the human visual system. I'd love to hear about more rigorous work in this area - most things I read have boiled down to "this way works better on these images".

It's interesting for example that using Sinc-type filters to resize truly linear data, like that from HDR cameras, usually gives rise to horrible dark haloing artifacts around small specular highlights, despite that being the most "physically correct" way to do it. Doing the same operation in a more perceptual space immediately sorts out the problem.

There's always an impetus to get higher resolution and quality at the offline stage though, as people get used to improving technology. It wouldn't be outrageous to have a 4k offline now, because people with 4k TVs at home will say "Why can't we? I want to see everything!", even if it doesn't particularly enhance the editor's work.

It would still be done with lower bitrate files, because original 4k material from digital cinema cameras is beyond what most machines are happy with.

    sox mo.wav -e unsigned -b 8 -c 1 -r 48k mo.raw
    bytes=`stat -f %z mo.raw`
    width=`echo sqrt\($bytes\) | bc`
    square_bytes=`echo $width \* $width | bc`
    dd if=mo.raw of=mo_square.raw bs=$square_bytes count=1
    gm convert -depth 8 -size ${width}x${width} gray:mo_square.raw -quality 50 mo_square.jpg
    gm convert mo_square.jpg gray:mo_square_jpg.raw
    sox -e unsigned -b 8 -c 1 -r 48k -t raw mo_square_jpg.raw mo_jpg.wav

https://en.wikipedia.org/wiki/Halton_sequence

https://books.google.co.uk/books?id=DirOQ_PELlgC&lpg=PA999&o...

FYI I tested Safari 9.1.1 (11601.6.17) and it failed on a whole bunch of the tests, including, frighteningly, the untagged HD 709 H264 :(

For HDR, a PQ (perceptual quantisation) encoding curve is already standardised by SMPTE - page 8 in these slides goes through the process of how it was worked out, right from human visual system basics: https://www.smpte.org/sites/default/files/2014-05-06-EOTF-Mi...

Given the abundance of log or gamma encodings for display imagery you might wonder why true linear 16-bit float is so common in CG production - why not log encode those 16 bits and get loads smoother gradients? Maybe the answer is that during production those linear files often also encode non-image data like vertex positions and normals, and perceptually "good" quantisation of those could lead to unexpected precision problems...

I have had to take increasingly drastic measures to keep it running on modern Linuxes though, and on OS X it sadly now seems impossible :(