Transcode iPhone Logarithmic Footage Without Loosing Log Color Information

Siru · edit-2 2 个月前

Transcode iPhone Logarithmic Footage Without Loosing Log Color Information

A_norny_mousse@feddit.org · 2 个月前

So you made a video of a scrolling log? For text to remain readable, that requires loads of data, less compression. Video codecs are not really built for this.

Mr Hindsight says you should’ve stored it as text right from the start.

Anyhow, the washed out colors are basically lack of detail, right?

The whole video needs maximum motion detection. Reduce the resolution, but make sure the bitrate is not (relatively) reduced.

Original:

3840x2160, 790587 kb/s, 29.99 fps

Let’s say you want 1920x1080, that’s a quarter of the original, so you should make sure the transcoding process stays at +/- a quarter the original bitrate (also be aware the difference of kb vs kB) and same framerate.

This should make sure the detail is the same.

Don’t expect the result to be satisfactory after the first try, you probably need to tweak settings more. https://ffmpeg.org/ffmpeg-all.html

Siru · 2 个月前

Thank you for the reply. I guess I didn’t make myself entirely clear in the original text, but I am talking about logarithmic color information, for better post production color grading. Not a text log.

The actual video is actually a frontal shot of a person talking like you would see in a newsroom. There is no text present in the video.

But yes, I absolutely agree with you, storing a text log as a video would be very inefficient and would require a huge amount of bitrate.

A_norny_mousse@feddit.org · edit-2 2 个月前

I am talking about logarithmic color information, for better post production color grading. Not a text log.

Right. Well, essentially my reply stands: that’s a lot of fine-grained information, the video codec thinks it’s a movie and it should be reduced.

edit: considering the video is more diverse than I assumed you should also look into 2-step encoding.

Siru · 2 个月前

I asked this same question on Reddit as well and figured I would copy over the answers that were given there so that Lemmy starts building up more searchable content/information.

Reply from @bobbster574@reddit.com

So the log data is just the way the luminance is stored in the image. It is the reason it is washed out; the image is being interpreted as a standard rec.709 SDR video when it isn’t. Log is often completely unlabelled leaving you to make sure youre using the correct operations for that specific log format.

Ffmpeg shouldn’t affect the log gamma unless you apply a lut or perform tonemapping to transform the image. That said, I’m not sure if ffmpeg will pass through all your original metadata about shooting settings which may or may not affect the processing in your editing software.

If you’re seeing significant colour shifts, something has potentially gone wrong but it’s also worth making sure that you check with your full processing pipeline rather than just a standard video player as it might be differences in interpretation between formats/metadata/etc rather than differences in pixel data.

This is also worth doing to make sure that your downsampling and compression retain enough quality for your purposes.

As the file is encoded in ProRes, it may actually be worth keeping the original resolution but compressing to high bitrate HEVC/H.265 which will generally not present any notable artefacts but still allow you to compress down to ¼-½ the size.

Reply from @ThiccBruhMoment@reddit.com

If they use av1, they should be able to hit ⅒ size and still have perfect quality. svtav1 preset 4 crf 20 should work.