Image sequence into video - Codec nightmare, help please!

[heihei]

Hello everybody,

I come in peace, cos really, I have been trying to find an answer to this phenomenon in all the friggin net, I've gone through russian, spanish, italian, thai, german, korean, japanese and indian forums, nothing at all. Threads were left always unanswered. Looks like nobody had this problem with codecs? I can't believe it! I have heard from this site and I gained hope again when seeing the interesting topics being discussed in here and the good workflow that seems to have. Can anyone help me please?

In Maxwell Render, a software for real light calculation, one can realise what it's called "Mutlight Sequence". Once the static render is made, it is possible to play with the lights of the scene and make an animation of the ambiance afterwards by rendering image y image the progress of its lights. Till here, okie dokie. Images are rendered in 16bits, 1800x1099px (Full Frame 5D MARK II HD for rendering) and in png to facilitate non degrading quality when joining them into a video.

I made a test for you with a Knot along with an infinite plane for studio. Lights are real 40W panels and camera settings real 5D MARK II settings. You will see that although the images are rendered correctly, when joining them into a video and therefore using a compressor, it starts transforming it into a picasso. The only way I have found to be working is not to compress, yes, ok: 7 seconds of video 1,5GB.

Images, around 1000:




Still of the video H264 vs real PNG image:





Tests:

1) In low resolution, it works. However, this can't never ever be used for a client, so it's out.

https://sendvid.com/aqkogw3u


2) High resolution, 1800x1099px = Tried in Photoshop Video Rendering, ffmpeg, VirtualDub, Photolapse, Premiere, Vegas using all codes I found, all parameters I could deduce would work the best and still nothing. H264 didn't work either. This is the result of H264, the others were really epic, worth an exhibit for its breaking and ghost lights.

https://sendvid.com/9wzl9usr


Does anybody know how to make these horrible "waves" be smooth as in the video with no compression? Of course, this video of 1,5GB I can't show it as by merely recording the screen or putting it online it gets conversed. But I guess you can imagine it. Is there any specific H264 parameter for such cases or should I really go find a specific codec for this problem? In that case, which?

THANK YOU VERY MUCH!!!

[hech54]

High resolution, 1800x1099

That doesn't sound right.

[smrpix]

You've got banding -- essentially quantum leaps in what you hope is a smooth transition. It shows up in your .png as well, it just calls less attention to itself when the image is static.

You need to add dithering to make the edges of the bands less distinct frame to frame.

[sneaker]

1. Make sure pictures are properly dithered down before being fed to the h.264 encoder. For low bitrates ordered dithering might be preferable.
2. To not create banding using H.264 you need
- bitrate, lots of it.
- if possible use 10 bit encoding (not compatible with most things so this may not be an option for you)
See more suggestions made here.

[racer-x]

You may also try ProRes, it's a common pro codec...

ffmpeg -i your/image/sequence -c:v prores -profile:v 3 -threads 8 -an -f mov output.mov

[aedipuss]

i work with a lot of raw from magic lantern cams and afaik the 5D Mk II, has a maximum resolution of 1880×720. where the 1099p came from i haven't a clue and it is not a resolution anyone in their right mind would choose.

[jagabo]

Yes, you need more noise and more bitrate. Or 10 bit encoding.

[heihei]

Thank you very much to all of you! It is great to receive all this feedback, I am thanking each of you.

I will try to spare some time next week to focus on this and show you the results as soon as I get the hang of it.

Thanks indeed. Have a good week.

[jagabo]

as I get the hang of it

The main issue is that YUV (used in most digital video) uses only 220 intensities, whereas RGB uses 256. So when those 220 shades of grey in a shallow gradient are displayed as 256 shades of grey on an RGB display (almost every display technology is RGB) there are shades where the brightness increases in steps of two rather than steps of one.

In addition, you may find that the conversion results in impure grey (or other) shades. That is, instead of R, G, and B being equal you may find some bands where the three values are not the same. So after an RGB (png image) to YUV (digital video) to RGB (final display) round trip you may find that a band that started with the R,G,B values 120, 120, 120 comes back as 121, 120, 120. That slightly red tinged ban will be vary obvious between pure grey bands of 119, 119, 119 and 221, 221, 221.

Even 8 bit (per channel) RGB isn't sufficient to give perfectly smooth gradients. You will always see banding between some colors in noiseless shallow gradients.

Adding noise to the signal helps hide these deficiencies. Too little bitrate (throwing out the noise) brings them back.