filmulator-gui VS reclaimail

Let's look at this from a perspective of Shannon's Information Theory. Cinema is a double tranmissive system. First, the world has things & shapes: it is information. It transmit / sends information about itself via light, which bounces off it and scatters or bounces. This travels through first an air/liquid/vacuum medium (distorting in some cases) and then the lens's optical medium. Then it impacts either a shutter (blocking the light) or if the shutter is open a frame of film, which is actually a lot of independent little film grains on a transmissive medium. Ok, we have now received the information, and the shutter closes and advances to the next frame, to repeat another reception.

Film is kind of interesting because the process of getting the information isn't done there. We also have to re-broadcast the film out, but honestly, that part is kind of boring: shine light through the developed film and it attenuates some parts of the light more than others, reproducing the information encoded on developed film quite directly & without loss.

So far, this has all been modelled pretty well by this project. We have fancy lens optics, reproducing the light-capture system of a camera. What's missing / un-canny valley so far is that the virtual world is usually a fairly poor facimile of the real world. The modelling straight up isn't as good. How things animate and move lack a subtlty of complex motion that real bodies in motion carry. There's a host of small issues around how light interacts/bounces off subjects that we don't model well in Blender or most systems: subsurface scattering effects aren't as fancy as they could be, the physical based rendering models aren't complex enough, the air itself as as a medium isn't well modelled. There's a huge combo of things the virtual worlds aren't as good at as the real world, and there's so many behaviors and nuances of things in the real world that virtual worlds usually don't capture as well. This largely defines the uncanny valley.

But, just to throw a little more fuel on the fire: this project also is missing another step in cinema that I skipped above. I don't think this is where the uncanny valley problem is, but I think it's a pretty sizable difference between film and digital cinema. Film has another tranmission process that I didn't describe above!

So, we've shot our movie. Now what? Well, we develop the film. What is developing? Well, we emerse the film in an activation bath to develop the exposed silver-halide crystals better known as film grains. There's information trapped in these crystals, they're at a certain state, and we have a chemical process which sends this information out, through a medium. The medium is the chemical developer, which turns the exposure into developed film grain, which is the received information from this system.

One of the really crazy things to me is that developing film is not at all like reading exposure values off a digital sensor. Because the process happens over time chemically, and the process itself is actively consuming the film developer as it works, which creates little local pockets where there's less developer. The process is non-linear. A heavily exposed scene will consume the developer and reduce further development speed not just for that film grain, but for the area around it.

Again, this isn't the uncanny valley problem. But it's still something missing from digital cinema, from this effort, that makes it substantially different from film cinema. There's projects like Filmulator https://filmulator.org/ that I love and adore which can simulate chemical development of film from RAW images. I'd love to see Virtual Blender Camera team up with efforts like these, to create a more genuine film-cinema feel, that models more than just the optical capture systems.

I'd also (re-)add: film is just one part of a transmission process.

Film has to be developed into something. And that's a chemical process, which is non-linear. Developer, the bath you put film in to activate the still blank but exposed reel, to turn the grains into actual "developed" photo, is a complex analog process. "Developer" is expended while developing film & becomes less effective at developing, creating a much stronger local contrast across pictures in a natural chemical way.

There's a pretty complex Shannon Information Theory system going on here, which I'm not certain how to model. There's maybe a information->transmit->medium->receive->information model between the scene and the film. Then an entirely separate information->transmit->medium->recieve->information model between the undeveloped scene and what actually shows up when you "develop" the film.

As you say, there are quite a variety of film types with different behaviors. https://github.com/t3mujin/t3mujinpack is set of Darktable presets to emulate various types of film. But the behavior of the film is still only half of the process. As I said in my previous post, developing the film is a complex chemical process, with lots of local effects for different parts of the image. There's enormous power here. https://filmulator.org/ is an epic project, that, in my view, is incredibly applicable to almost all modern digital photography, that could help us so much, to move beyond raw data & help us appreciate scenes more naturally. It's not "correct" but my personal view is the aesthetic is much better, and it somewhat represents what the human eye does anyways, with it's incredible ability to comprehend & view dynamic range.

How does this compare to my Filmulator, which basically runs a simulation of stand development?

https://filmulator.org

(I've been too busy on another project to dedicate too much time to it the past year, and dealing with Windows CI sucks the fun out of everything, so it hasn't been updated in a while…)

She's Got The Look! Many people spend so much time trying to make their digital photos look like film (and massive props to /u/CarVac for his development of Filmulator because it's awesome), but with film that's effortless and automatic. Want to make your photos look like they were shot on Ektar? Use Ektar. Portra? Use Portra. And Velvia, and Provia and Cinestill, and so on.

> I don't want to do elaborate stuff like working with masks / applying filters to sections of the photo only. Only thing I usually do is increase saturation, and, rarely, brightness/aperture.

I don't think you're the intended audience for darktable. Try https://filmulator.org/

There's a list in the FAQ. I try to stick to free and open-source software. Darktable, RawTherapee, and Filmulator have varying levels of complexity.

Shameless self-plug: https://filmulator.org/

AppImages are only as self-contained as the author made them be. There's also upper limits to how self-contained they are. While some terminal and bitmap only X11 app can be compiled as static binaries, anything that depends on system libraries needs to be compiled with an older version of glibc. The best example is libGl (GLX or EGL) for hardware 3D acceleration or libvdpau for hardware media decoding. You can't just bundle those, you have to use the system ones. OpenSSL and a few other a libs you usually want to use the system one and have a built-in fallback because of security concerns.

Making perfect AppImages is often possible, but the automated tooling isn't smart enough. A proper AppImage (this one is by me) look like this: https://github.com/Elv13/reclaimail/blob/master/docker-edito... . Obviously this doesn't scale very well to projects with 300 dependencies like Digikam. My NeoVIM appimage linked above "really, really" bundles all dependency and compile your NeoVIM config to luajit bytecode. It's 3.9mb compared to the upstream one which is 15mb without any config. Note than 0.7mb of that 3.9 is the spellcheck dictionary, 0.4 my enormous config, 0.5 the AppImage overhead and 0.7 all the legacy plugins still written in vimscript.

For the "VMs", they are actually just docker containers, so any provider work fine. Nothing really depends on the DNS, so I can move stuff rather easily. Sure, I lose /some/ stuff. Like obviously the PXE server for booting my desk phone and some IoT stuff actually need to physically be in my home network to work, but that's about it.