Recherche avancée

Sur d’autres sites (4355)

• FFmpeg : Removing black outline on overlay after alphamerge

  9 novembre 2023, par trmd

  Similar question : FFmpeg transparent PNG black outline issue

  


  When using FFmpeg to create a GIF from an mp4, masking the video using alphamerge and a PNG-mask, and overlaying a circle outline, black lines occur on both the video and the circle in the final GIF.

  


  From this question, some suggestions are made to add alpha=premultiplied and format=rgb,format=yuv420p in the overlay-filter. This removes the black line (on the circle), but the masking from alphamerge no longer works.

  


  Filter used which generates black outlines :

  


  [0][1]alphamerge[merged];
[merged][2:v]overlay=
    format=auto:
    alpha=premultiplied[withCircleOverlay];
[withCircleOverlay]scale=${size}x${size}[scaled];
[scaled]split[s0][s1];
[s0]palettegen=reserve_transparent=on:transparency_color=ffffff[p];
[s1][p]paletteuse


  


  Filter used which removes outlines, but also cropping :

  


  [0][1]alphamerge[merged];
[merged][2:v]overlay=
    alpha=premultiplied:
    format=rgb,format=yuv420p[withCircleOverlay];
[withCircleOverlay]scale=${size}x${size}[scaled];
[scaled]split[s0][s1];
[s0]palettegen=reserve_transparent=on:transparency_color=ffffff[p];
[s1][p]paletteuse


  


  Command used :

  


  ffmpeg -i movie.mp4 -i mask.png -i circle.png -filter_complex <filter> output.gif&#xA;</filter>

  


  What I've tried :

  


  

  • Changing the format-parameter on overlay to a lot of different values.

  


  • Changing the order of the filters.

  


  • Playing around with running multiple ffmpeg-passes : First doing the merging, saving this to a file, and then adding the circle afterwards. I think this in principle should work if I tinker with it enough.

  


  


  Are there any ways to get around this issue ?

  


  Image with black outlines

  


  

  


  Image without outline, but also without alphamerge cropping

  


  

  


• FFmpeg cant recognize 3 channels with each 32 bit

  4 avril 2022, par Chryfi

  I am writing the linearized depth buffer of a game to openEXR using FFmpeg. Unfortunately, FFmpeg does not adhere to the openEXR file specification fully (like allowing unsigned integer for one channel) so I am writing one float channel to openEXR, which is put into the green channel with this command -f rawvideo -pix_fmt grayf32be -s %WIDTH%x%HEIGHT% -r %FPS% -i - -vf %DEFVF% -preset ultrafast -tune zerolatency -qp 6 -compression zip1 -pix_fmt gbrpf32le %NAME%_depth_%d.exr.

  


  The float range is from 0F to 1F and it is linear. I can confirm that the calculation and linearization is correct by testing 16 bit integer (per pixel component) PNG in Blender compositor. The 16 bit integer data is written like this short s = (short) (linearzieDepth(depth) * (Math.pow(2,16) - 1)) whereas for float the linearized value is directly written to OpenEXR without multiplying with a value.

  


  However, when viewing the openEXR file it doesn't have the same "gradient" as the 16 bit png... when viewing them side by side, it appears as if the values near 0 are not linear, and they are not as dark as they should be like in the 16 bit png.
(And yes, I set the image node to linear), and comparing it with 3d tracking data from the game I cant reproduce the depth and cant mask things using the depth buffer where as with the png I can.

  


  How is it possible for a linear float range to turn out so different to a linear integer range in an image ?

  


  UPDATE :

  


  I now write 3 channels to the ffmpeg with this code

  


  float f2 = this.linearizeDepth(depth);

buffer.putFloat(f2);
buffer.putFloat(0);
buffer.putFloat(0);


  


  the byte buffer is of the size width * height * 3 * 4 -> 3 channels with each 4 bytes. The command is now -f rawvideo -pix_fmt gbrpf32be -s %WIDTH%x%HEIGHT% -r %FPS% -i - -vf %DEFVF% -preset ultrafast -tune zerolatency -qp 6 -compression zip1 -pix_fmt gbrpf32le %NAME%_depth_%d.exr which should mean that the input (byte buffer) is expecting 32 bit floats with 3 channels.

  


  FFmpeg is somehow splitting up channels or whatever... could be a bug, could be my fault ?

  


• Writing linear float range to openEXR turns out non linear

  3 avril 2022, par Chryfi

  I am writing the linearized depth buffer of a game to openEXR using FFmpeg. Unfortunately, FFmpeg does not adhere to the openEXR file specification fully (like allowing unsigned integer for one channel) so I am writing one float channel to openEXR, which is put into the green channel with this command -f rawvideo -pix_fmt grayf32be -s %WIDTH%x%HEIGHT% -r %FPS% -i - -vf %DEFVF% -preset ultrafast -tune zerolatency -qp 6 -compression zip1 -pix_fmt gbrpf32le %NAME%_depth_%d.exr.

  


  The float range is from 0F to 1F and it is linear. I can confirm that the calculation and linearization is correct by testing 16 bit integer (per pixel component) PNG in Blender compositor. The 16 bit integer data is written like this short s = (short) (linearzieDepth(depth) * (Math.pow(2,16) - 1)) whereas for float the linearized value is directly written to OpenEXR without multiplying with a value.

  


  However, when viewing the openEXR file it doesn't have the same "gradient" as the 16 bit png... when viewing them side by side, it appears as if the values near 0 are not linear, and they are not as dark as they should be like in the 16 bit png.
(And yes, I set the image node to linear), and comparing it with 3d tracking data from the game I cant reproduce the depth and cant mask things using the depth buffer where as with the png I can.

  


  How is it possible for a linear float range to turn out so different to a linear integer range in an image ?