You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
DDV creates jpeg stills at around 75% quality. These artifact-laden images are then analyzed and iteratively "dreamt", then saved again in the lossy jpg format. While I was battle-testing the shell scripts, I noticed an incredible loss of fidelity in the resulting video.
Of the many other image formats available, I recommend png. This will probably make the entire pipeline slower, but will result in higher quality.
In keeping with the "choose your own toolkit" approach, I could imagine making a PR that allows the user to choose to sacrifice performance for quality by defining the compression [ png | jpg20 | jpg40 | jpg60 | jpg80 ].
Should the user choose png, then the service should probably ALWAYS try to pngcrush the images before continuing.
Shall I go ahead with this?
The text was updated successfully, but these errors were encountered:
DDV creates jpeg stills at around 75% quality. These artifact-laden images are then analyzed and iteratively "dreamt", then saved again in the lossy jpg format. While I was battle-testing the shell scripts, I noticed an incredible loss of fidelity in the resulting video.
Of the many other image formats available, I recommend png. This will probably make the entire pipeline slower, but will result in higher quality.
In keeping with the "choose your own toolkit" approach, I could imagine making a PR that allows the user to choose to sacrifice performance for quality by defining the compression [ png | jpg20 | jpg40 | jpg60 | jpg80 ].
Should the user choose png, then the service should probably ALWAYS try to pngcrush the images before continuing.
Shall I go ahead with this?
The text was updated successfully, but these errors were encountered: