Recherche avancée

Sur d’autres sites (7801)

• Why iFrame is a good idea

  15 octobre 2009

  I’ve seen some hilariously uninformed posts about the new Apple iFrame specification. Let me take a minute to explain what it actually is.

  First off, as opposed to what the fellow in the Washington Post writes, it’s not really a new format. iFrame is just a way of using formats that we’ve already know and love. As the name suggests, iFrame is just an i-frame only H.264 specification, using AAC audio. An intraframe version of H.264 eh ? Sounds a lot like AVC-Intra, right ? Exactly. And for exactly the same reasons - edit-ability. Whereas AVC-Intra targets the high end, iFrame targets the low end.

  Even when used in intraframe mode, H.264 has some huge advantage over the older intraframe codecs like DV or DVCProHD. For example, significantly better entropy coding, adaptive quantization, and potentially variable bitrates. There are many others. Essentially, it’s what happens when you take DV and spend another 10 years working on making it better. That’s why Panasonic’s AVC-Intra cameras can do DVCProHD quality video at half (or less) the bitrate.

  Why does iFrame matter for editing ? Anyone who’s tried to edit video from one of the modern H.264 cameras without first transcoding to an intraframe format has experienced the huge CPU demands and sluggish performance. Behind the scenes it’s even worse. Because interframe H.264 can have very long GOPs, displaying any single frame can rely on dozens or even hundreds of other frames. Because of the complexity of H.264, building these frames is very high-cost. And it’s a variable cost. Decoding the first frame in a GOP is relatively trivial, while decoding the middle B-frame can be hugely expensive.

  Programs like iMovie mask that from the user in some cases, but at the expensive of high overhead. But, anyone who’s imported AVC-HD video into Final Cut Pro or iMovie knows that there’s a long "importing" step - behind the scenes, the applications are transcoding your video into an intraframe format, like Apple Intermediate or ProRes. It sort of defeats one of the main purposes of a file-based workflow.

  You’ve also probably noticed the amount of time it takes to export a video in an interframe format. Anyone who’s edited HDV in Final Cut Pro has experienced this. With DV, doing an "export to quicktime" is simply a matter of Final Cut Pro rewriting all of the data to disk - it’s essentially a file copy. With HDV, Final Cut Pro has to do a complete reencode of the whole timeline, to fit everything into the new GOP structure. Not only is this time consuming, but it’s essentially a generation loss.

  iFrame solves these issues by giving you an intraframe codec, with modern efficiency, which can be decoded by any of the H.264 decoders that we already know and love.

  Having this as an optional setting on cameras is a huge step forward for folks interested in editing video. Hopefully some of the manufacturers of AVC-HD cameras will adopt this format as well. I’ll gladly trade a little resolution for instant edit-ability.

• Fill patterns

  9 juin 2010, par Mikko Koppanen — Imagick, PHP stuff

  My work life has been quite busy lately and I haven’t had a chance to sit down and blog. I have been touring around London and some parts of the northern England consulting and organizing some training here and there. Luckily I have had the chance to do some work on Imagick and the 2.2.0 beta release is getting closer. The internal structure was completely restructured and broken down into several smaller files. During this time Imagick was adapted to follow the PHP Coding Standards more closely. Still a work in progress

  I committed slightly modified version of this example to PHP Manual http://uk.php.net/manual/en/imagick.examples.php page a few days ago. The example illustrates using an image as a part of a named fill pattern. The fill pattern is used to annotate text but the named pattern could also be used to fill any shapes that allow fill to be specified (include circles, ellipses, rectangles, polygons etc etc). The code itself is pretty straight forward : Read the image, create the pattern and use the pattern as a fill.

  The ice formations image is from http://www.photoeverywhere.co.uk/west/winterholiday/slides/iceformations5679.htm.

  php

  < view plain text >

  1. < ?php
  2.  
  3. /* Create a new imagick object */
  4. $im = new Imagick( ’iceformations5679.JPG’ ) ;
  5.  
  6. /* Create imagickdraw object */
  7. $draw = new ImagickDraw() ;
  8.  
  9. /* Start a new pattern called "ice" */
  10. $draw->pushPattern( ’ice’ , 0 , 0 , 50 , 50 ) ;
  11.  
  12. /* Composite the image on the pattern */
  13. $draw->composite( Imagick: :COMPOSITE_OVER, 0, 0, 50, 50, $im ) ;
  14.  
  15. /* Close the pattern */
  16. $draw->popPattern() ;
  17.  
  18. /* Use the pattern called "ice" as the fill */
  19. $draw->setFillPatternURL( ’#ice’ ) ;
  20.  
  21. /* Set font size to 52 */
  22. $draw->setFontSize( 52 ) ;
  23.  
  24. /* Annotate some text */
  25. $draw->annotation( 5, 50, "Hello World !" ) ;
  26.  
  27. /* Create a new canvas and white image */
  28. $canvas = new Imagick() ;
  29. $canvas->newImage( 310, 70, "white" ) ;
  30.  
  31. /* Add black border around the resulting image */
  32. $canvas->borderImage( ’black’, 1, 1 ) ;
  33.  
  34. /* Draw the ImagickDraw on to the canvas */
  35. $canvas->drawImage( $draw ) ;
  36.  
  37. /* Set the format to PNG */
  38. $canvas->setImageFormat( ’png’ ) ;
  39.  
  40. /* Output the image */
  41. header( "Content-Type : image/png" ) ;
  42. echo $canvas ;
  43.  ?>

  And the result is here :

  

• Revision 37939 : - suppression des points et espaces dans le champs numéro avant ...

  2 mai 2010, par yffic@… — Log

  suppression des points et espaces dans le champs numéro avant l’enregistrement - Le numéro de l’article doit d’afficher dans le champ numéro même sur le champs titre n’a pas de structure multi - Ajout dans les paramètres d’init des forms contenant des éléments de classe "multilang" ET des containers (...)