@cegaton, @troy_s does option 3: guess at jpg<-->linear transform give results so terrible, that it is never worth trying?

@JordanSzubert when you import images encoded in sRGB into blender, they get linearized, by applying an inverse transform. But the resulting image values remain in display linear (between 0-1), giving you roughly 2.5 stops over middle gray. Filmic blender works on a much larger scale, using a much larger dynamic range (up to 25 sotps).

You would think then that if you scaled your display linear image (by simply multiplying it's values 16 times for example) you would then get values that would resemble those of the original scene where the image was made.

But the problem lies in how the camera decided how to distribute the tonal values originally, when you first made the image. Each camera will give you a different result, so that you get a "pleasing" looking image in display referred values. Whatever transformation happened there is already "baked" into the image.

But let's say you actually had access to the secret sauce used for mapping the tones in the original photo, Then there is the issue of how many bits are used to distribute those tones in an 8 bit format. You only have 256 tones from black to white, once you scale those values, you would have no way to reconstruct the intermediate tones and the image would have gaps in the information.

@JordanSzubert read blender.stackexchange.com/questions/46825/…

@JordanSzubert blenderguru.com/tutorials/secret-ingredient-photorealism

@cegaton the results won't be perfect, obviously, but will it be always worse compared to display referred compositing?

@JordanSzubert The point is that if you start exploring using Scene Refferred images or log encoded ones, you will not only get better quality and more control in your work, but the integration will be a lot easier. It is true that a lot of image makers have been composing display referred images using photoshop for a long time and fooling everybody with them... at the end of the day is your choice.

@JordanSzubert @cegaton covered everything very well. If we play the mental game where you knew the camera's secret sauce baked into a JPEG, yes the results would be much better than where you started, but equally yes it would be quite sub optimal. Best source of comprehension here is to try it!

@JordanSzubert The main issue would be as per the 256 steps comment from @cegaton above; if you try to map the original scene's values into those 256 tones, and we assume even a less than optimal ten or so stops, we can begin to see the problem.

@JordanSzubert The first issue is that the JPEG is "aesthetically encoded", that is, it is encoded to look like a photo that someone would look at. That means that the scene values have been bent nonlinearly to augment contrast and appearance. If we were to start with a perfect log encoded image (log only because it is efficient to encode scene referred values into) we would have a close to uniform distribution of bits to stops of light. 256/10 = about 25 code values per stop.

@JordanSzubert But with an aesthetic image, we have permanently compressed and extended some regions that we can't recover that data from. So our less than optimal 25 steps would be diminished quite significantly for some regions and more for others.

@JordanSzubert As a general rule, log encodes are quite sub-optimal at 8 bits or less. A minimum would be around 10 bits or greater. So if we realize this and couple it with an aesthetic baked result, one ends up quite significantly crippling the data.

The TL;DR is that once one understands the value of scene referred data, it leads to "How to encode a file using optimized bits but still have access to scene referred data?" which leads to log encoded imagery. Once you understand why log exists (and there are many different log encodes, like many-many :) ) you can begin to see why output referred aesthetic encodes are sort of a one-way street. Think of it as being an optimized for streaming low bitrate MP3, and +

- wanting to remix / mix / master off of it. It would be a very tough chore due to the compression of the values.

At any rate, good on you for sticking at it and asking questions. Keep on it, and everything will only get more and more clear. Ask more questions and I am quite sure folks that frequent here can help you to flesh things out further.

Most importantly, try things. Seeing how an aesthetic image bent back to the scene referred domain can be very useful. You can luckily do this already, perfectly, with perfect decoding. How? Use the Filmic set.

If you save out a complex scene (try classroom lit to filmic and render) to 8 bit JPEG using Filmic Log, you could then load that 8 bit image and flag it as Filmic Log Encoding Base and it will get returned to the scene referred domain accurately, albeit with reduced bit depth.

Try adjusting exposure on it in the scene referred domain. How does it degrade? Try doing other things. You will see that it, even in the base log, will fall apart quite quickly.

With a little help and effort, you could take that further and decode an aesthetic version using Base Contrast and you would very likely see things immediately.

@cegaton Almost finished the blasted project?

I am very keen to hear all of the issues along the way.

@troy_s almost there!

Exciting!

@cegaton Do you / are you able to plan for a series of posts deconstructing some of the issues and how you worked through the project?

@troy_s yes I think I'm going to start some sort of blog. It's been a fun experience!

I bet. How many folks involved in total?

@troy_s just me... that's why it took so long.

Did you do all of the footage as well?

Is it a personal project?

@troy_s it is an odd form documentary for Public Television

@troy_s I'll let you know when it's done.

Can't wait.

What is the subject matter of the documentary?

(I have to live vicariously through folks like you of late as I have had zero time to do anything.)

(Thinking about picking up a GH5 though.)

@troy_s the film is about Oscar Zeta Acosta, writer and activist, his life from the 1930s to his disappearance in 1974...

Wow. Very interesting. Are the VFX / animated elements abstract then?

@troy_s some are abstract and silly, some are just background elements for actors re-enacting interviews.

also, if i wanted to see what jpg decoded from filmic base contrast looks like, i'd need command line, or was some node added?

(Oh boy, someone just discovered albedo and didn't realise it... blenderartists.org/forum/…)

@JordanSzubert load it in the UV?image editor, by default is going to read it as sRGB, but you can manually select the color space

@JordanSzubert You would need to do a little modification. You would need a custom transform in the config.ocio.

@JordanSzubert Are you comfortable editing text files?

@JordanSzubert Hold tight. Let me give you a gist of the transform.

@JordanSzubert I haven't tested this, but this is how it should look gist.github.com/sobotka/b064b0688240966de4517fd8113c510d

So:

1) Create a copy / backup of your existing config.ocio

2) Somewhere below the existing Filmic Log Encoding transform, add that stanza.

3) Render out a semi-complex scene such as classroom or something with a decent wide dynamic range of values. Save two versions as a TIFF at 8 and 16 bits using Filmic Log Encoding Base View. Save a second version as a TIFF at 8 bits using the Filmic Log Encoding Base + Base Contrast Look.

4) Start a clean Blender project and load all three as emission planes or whatever you like / however you want. Set the 8 and 16 bit Filmic Log versions to Filmic Log Encoding via the UV panel. Set the third 8 bit with baked contrast to the custom transform I just created a Gist for above.

Compare.

@JordanSzubert That help?

@troy_s yeah, i'll test when i get to blender