Recherche avancée

Sur d’autres sites (12202)

• Perspective transformations

  4 février 2009, par Mikko Koppanen — Imagick, PHP stuff

  Finally (after a long break) I managed to force myself to update the PHP documentation and this time it was distortImage code example. Things have been hectic lately but that does not quite explain the 6 months(?) break between this and the previous post. As a matter of a fact there is no excuse for such a long silence so I will try to update this blog a bit more often from now on.

  Back in the day I used to blog the examples and update the documentation if I remembered but I am trying to fix this bad habit. Most of the latest examples have been updated in to the manual. In the case of the two last examples I updated the documentation first and then blogged on the subject.

  I took some time to actually understand the perspective transformations properly using the excellent ImageMagick examples (mainly created by Anthony Thyssen) as a reference. The basic idea of perspective distortion seems simple : to distort the control points to new locations. Grabbing the syntax for Imagick was easy, an array of control point pairs in the form of :

  php

  < view plain text >

  1. array(source_x, source_y, dest_x, dest_y ... )

  The following example uses the built-in checkerboard pattern to demonstrate perspective distortion :

  php

  < view plain text >

  1. < ?php
  2. /* Create new object */
  3. $im = new Imagick() ;
  4.  
  5. /* Create new checkerboard pattern */
  6. $im->newPseudoImage(100, 100, "pattern:checkerboard") ;
  7.  
  8. /* Set the image format to png */
  9. $im->setImageFormat(’png’) ;
  10.  
  11. /* Fill background area with transparent */
  12. $im->setImageVirtualPixelMethod(Imagick: :VIRTUALPIXELMETHOD_TRANSPARENT) ;
  13.  
  14. /* Activate matte */
  15. $im->setImageMatte(true) ;
  16.  
  17. /* Control points for the distortion */
  18. $controlPoints = array( 10, 10,
  19.             10, 5,
  20.  
  21.             10, $im->getImageHeight() - 20,
  22.             10, $im->getImageHeight() - 5,
  23.  
  24.             $im->getImageWidth() - 10, 10,
  25.             $im->getImageWidth() - 10, 20,
  26.  
  27.             $im->getImageWidth() - 10, $im->getImageHeight() - 10,
  28.             $im->getImageWidth() - 10, $im->getImageHeight() - 30) ;
  29.  
  30. /* Perform the distortion */ 
  31. $im->distortImage(Imagick: :DISTORTION_PERSPECTIVE, $controlPoints, true) ;
  32.  
  33. /* Ouput the image */ 
  34. header("Content-Type : image/png") ;
  35. echo $im ;
  36.  ?>

  Here is the source image :
  

  And the result :
  

• Anomalie #2467 : droits du rédacteur

  4 novembre 2013, par Suske -

  Bah, il me semble que :

  - selon /ecrire/ ?exec=configurer_contenu (" Qui peut proposer des sites référencés ? " / 6forum, 1comite,0minirezo => accéder au form de proposition
  - la validation et les modifications de ce qui est publié ou rejeté devrait par défaut être réservée aux 0minirezo (ça devrait être calqué sur les articles)

  Comme c’est des autorisations sur un plugin-dist j’ai mis une estimation du temps de debug ^^

• Unmapping memory-mapped images that are created during processing

  23 avril 2013, par user2309283

  I have a pretty big issue, although I only have the symptoms, and a theory on the cause.

  I have a C++ application under Windows 7x64 that uses system calls to FFMPEG 0.7.13 to extract frames from videos. When running, the parent application maintains a nice, predicable memory footprint in memory profilers (task manager, RAMMap) of about 2MB. I can see the individual calls to FFMPEG also come and go without incident. The trouble is, after about 100 calls to FFMPEG, and 70,000+ PNGs created (no one directory has more than 1500 pngs), the Windows memory page size raises gradually from about 2.5GB to over 7.0GB, and the system is brought to its knees. The sum of the processes for all users is no where near the reported Memory Page amount.

  I thought it might be Windows Search indexing related, so I turned off the indexing for the output directories in question using SetFileAttributes() and FILE_ATTRIBUTE_NOT_CONTENT_INDEXED, and while it seems to be working as advertised, it does not seem to combat the issue at hand. My current running theory is that all of these extracted PNGs are either fully or partially memory mapped, by FFMPEG or something else. I can also see the output PNGs under the RAMMap Physical Pages tab as standby mapped files.

  Question :
   Is there enough information here to possibly diagnose the exact problem ?
   Do I have a way to combat this issue ?

  Thanks in advance...