Recherche avancée

Sur d’autres sites (10404)

• ffmpeg 180 degree panoramic fisheye image to equirectangular / flat

  7 juillet 2024, par Willy62

  I am trying to get my Hikvision Panovu image of a sportsfield to look like a standard camera image, similar to what would be seen with a Veo solution / traditional camera.

  


  This is what the image would ideally look like with a little bit of zoom. Note the players are all upright and it looks "correct" and not skewed with the far end of the field in line with the horizon.

  


  veo sample image

  


  The original image looks like this (same field but other side). This is a 180 degree panoramic image from a Hikvision camera as found here.

  


  It provides the following output natively.

  


  hikvision native view

  


  I have had some luck converting the image with ffmpeg using the v360 filter. Note there is a downward tilt meaning I have to apply some yaw to correct it.

  


  v360=input=fisheye:output=rectilinear:ih_fov=180:iv_fov=87.5:d_fov=87.5:pitch=20:yaw=5:w=3840:h=2160


  


  And this gets the following output :

  


  deskewed v360 image

  


  So the challenge here to make the original image flat/equirect but to address the skew such that :

  


  

  • the players are orientated "upright"

  


  • the far sideline of the field looks like a straight line in line with the horizon

  


  • the image quality is preserved as best as possible

  


  


  With these cameras the image is 32MP so there is the opportunity to do an ePTZ into the area of interest.

  


  I suspect v360 isnt the right choice here and it is some remap-style filter, or perhaps I am best going across to gstreamer or similar.

  


  I tried an ffmpeg v360 filter and it partially works, but the players are still skewed because the top of the image is not wide enough. The issue can possibly be solved by correctly applying a couplex perspective filter, but I think this will only mask the issue and perspective requires a complex filter that hasn't worked for me so far.

  


• Revision 30246 : Corrections de grosses boulettes sql Correction d’une boulette dans la ...

  27 juillet 2009, par kent1@… — Log

  Corrections de grosses boulettes sql
  Correction d’une boulette dans la déclaration des champs
  On ne permet la demande de réencodage que depuis le document original sinon vive ma perte de qualité
  On affiche un message indiquant que c’est une version encodée issue d’un autre document s’il y a lieu de le faire
  On encode les sons dorénavant

• x264 Downsides of a high CRF (22) intermediary codec between conversions instead of lossless

  18 décembre 2019, par bobtheencoder

  I have a huge collection of video files that are in the range of CRF 16-20 taking up TB’s of space. The only need I have for these originals is that I have to encode them from time to time but the CRF of these final encodes is very low (CRF 26-28).

  I understand that a lossy to lossy converstion ALWAYS results in some quality loss but my question is what if the intermediate file is almost visually lossless compared to the final output.

  So to sum up, what quality difference should I expect from the following routes ?

  CRF 18 (original) -----> CRF 28 (final)
  
  CRF 18 (original) -----> CRF 22 (long-term storage) -----> Lossy  CRF 28 (final)