Recherche avancée

Sur d’autres sites (8482)

• lavfi/delogo : use weighted interpolation

  26 juin 2013, par Jean Delvare

  lavfi/delogo : use weighted interpolation
  The original delogo algorithm interpolates both horizontally and
  
  vertically and uses the average to compute the resulting sample. This
  
  works reasonably well when the logo area is almost square. However
  
  when the logo area is significantly larger than high or higher than
  
  large, the result is largely suboptimal.
  The issue can be clearly seen by testing the delogo filter with a fake
  
  logo area that is 200 pixels large and 2 pixels high. Vertical
  
  interpolation gives a very good result in that case, horizontal
  
  interpolation gives a very bad result, and the overall result is poor,
  
  because both are given the same weight.
  Even when the logo is roughly square, the current algorithm gives poor
  
  results on the borders of the logo area, because it always gives
  
  horizontal and vertical interpolations an equal weight, and this is
  
  suboptimal on borders. For example, in the middle of the left hand
  
  side border of the logo, you want to trust the left known point much
  
  more than the right known point (which the current algorithm already
  
  does) but also much more than the top and bottom known points (which
  
  the current algorithm doesn’t do.)
  By properly weighting each known point when computing the value of
  
  each interpolated pixel, the visual result is much better, especially
  
  on borders and/or for high or large logo areas.
  The algorithm I implemented guarantees that the weight of each of the
  
  4 known points directly depends on its distance to the interpolated
  
  point. It is largely inspired from the original algorithm, the key
  
  difference being that it computes the relative weights globally
  
  instead of separating the vertical and horizontal interpolations and
  
  combining them afterward.
  Signed-off-by : Jean Delvare <khali@linux-fr.org>
  
  Signed-off-by : Stefano Sabatini <stefasab@gmail.com>
  

  • [DH] libavfilter/vf_delogo.c
  • [DH] tests/ref/fate/filter-delogo

• Revision e606cac046 : Change meaning of cpi->sf.first_step and rename. Renamed cpi->sf.first_step to

  24 juin 2013, par Paul Wilkins

  Changed Paths :
   Modify /vp9/encoder/vp9_mbgraph.c

  
   Modify /vp9/encoder/vp9_mcomp.c

  
   Modify /vp9/encoder/vp9_mcomp.h

  
   Modify /vp9/encoder/vp9_onyx_if.c

  
   Modify /vp9/encoder/vp9_onyx_int.h

  
   Modify /vp9/encoder/vp9_rdopt.c

  
   Modify /vp9/encoder/vp9_temporal_filter.c

  
  
  Change meaning of cpi->sf.first_step and rename.

  Renamed cpi->sf.first_step to cpi->sf.reduce_first_step_size
  and changed its meaning such that it is a delta applied to
  reduce the default first step size (>> x) in the motion search
  rather than an absolute value.

  The default first step size is already changed according to the image
  dimensions (smaller for smaller images). cpi->sf.reduce_first_step_size
  now applies a further correction from the default.

  Change-Id : Ia94e08bc24c67b604831f980909af7e982fcd16d

• Making Sure The PNG Gets There

  14 juin 2013, par Multimedia Mike — General

  Rewind to 1999. I was developing an HTTP-based remote management interface for an embedded device. The device sat on an ethernet LAN and you could point a web browser at it. The pitch was to transmit an image of the device’s touch screen and the user could click on the picture to interact with the device. So we needed an image format. If you were computing at the time, you know that the web was insufferably limited back then. Our choice basically came down to GIF and JPEG. Being the office’s annoying free software zealot, I was championing a little known up and coming format named PNG.

  So the challenge was to create our own PNG encoder (incorporating a library like libpng wasn’t an option for this platform). I seem to remember being annoyed at having to implement an integrity check (CRC) for the PNG encoder. It’s part of the PNG spec, after all. It just seemed so redundant. At the time, I reasoned that there were 5 layers of integrity validation in play.

  I don’t know why, but I was reflecting on this episode recently and decided to revisit it. Here are all the encapsulation layers of a PNG file when flung over an ethernet network :

  
  
  

  So there are up to 5 encapsulations for the data in this situation. At the innermost level is the image data which is compressed with the zlib DEFLATE method. At first, I thought that this also had a CRC or checksum. However, in researching this post, I couldn’t find any evidence of such an integrity check. Further, I don’t think we bothered to compress the PNG data in this project long ago. It was a small image, monochrome, and transferring via LAN, so the encoder could get away with signaling uncompressed data.

  The graphical data gets wrapped up in a PNG chunk and all PNG chunks have a CRC. To transmit via the network, it goes into a TCP frame, which also has a checksum. That goes into an IP packet. I previously believed that this represented another integrity check. While an IP frame does have a checksum, the checksum only covers the IP header and not the payload. So that doesn’t really count towards this goal.

  Finally, the data gets encapsulated into an ethernet frame which has — you guessed it — a CRC.

  I see that other link layer protocols like PPP and wireless ethernet (802.11) also feature frame CRCs. So I guess what I’m saying is that, if you transfer a PNG file over the network, you can be confident that the data will be free of any errors.