Recherche avancée

Sur d’autres sites (4190)

• More Imagick refresh

  4 octobre 2013, par Mikko Koppanen — Imagick, PHP stuff

  I’ve committed quite a few changes lately, mainly removing excessive macro usage and making the code more robust. Large amounts of the code was written about six years ago and a lot of things have changed since. Among other things, I’ve probably become a lot better in C.

  Under the hood ImagickPixelIterator went through almost a full rewrite, a lot of the internal routines have been renamed and improved and I am happy to say that most of the (useless) macros have been removed.

  Some of the user visible/interesting features added recently :

  Countable

  Imagick class now supports Countable interface and calling count on the object returns amount of images currently in memory. For example for PDF files this is usually the amount of pages. This is purely syntactic sugar as the functionality was available before using the getNumberImages method. The usage of the countable is pretty simple : 021-countable.phpt.

  writeImageFile

  After tracking down (what I thought was) a bug related to writeImageFile not honouring the format set with setImageFormat I was advised that the format actually depends on the filename. The filename is set during reading the image and just calling setImageFormat and writeImageFile would cause the original file format to be written in the handle.

  There is now an additional parameter for writeImageFile for setting the format during the operation. The following test demonstrates the functionality and the issue : 022-writeimagefileformat.phpt.

  Memory Management

  One of the things that pops up now and then (especially from shared hosting providers) is whether Imagick supports PHP memory limits. Before today the answer was no and you needed to configure ImageMagick separately with reasonable limits.

  In the latest master version there is a new compile time flag –enable-imagick-zend-mm, which adds Zend Memory Manager support. This means that Imagick will honour the PHP memory limits and will cause “Out of memory” error to be returned in case of overflow. The following test demonstrates the “usage” : 023-php-allocators.phpt.

• Interfacing to an Xbox Optical Drive

  1er octobre 2013, par Multimedia Mike — xbox

  The next generation Xbox is going to hit the streets soon. But for some reason, I’m still interested in the previous generation’s unit (i.e., the original Xbox). Specifically, I’ve always wondered if it’s possible to use the original Xbox’s optical drive in order to read Xbox discs from Linux. I was never curious enough to actually buy an Xbox just to find out but I eventually came across a cast-off console on a recycle pile.

  I have long known that the Xbox has what appears to be a more or less standard optical drive with a 40-pin IDE connector. The only difference is the power adapter which I surmise is probably the easiest way to turn a bit of standardized hardware into a bit of proprietary hardware. The IDE and power connectors look like this :

  
  
  

  Thus, I wanted to try opening an Xbox and plugging the optical drive into a regular PC, albeit one that supports IDE cables, and allow the Xbox to supply power to the drive. Do you still have hardware laying around that has 40-pin IDE connectors ? I guess my Mac Mini PPC fits the bill, but I’ll be darned if I’m going to pry that thing open again. I have another IDE-capable machine buried in my closet, last called into service when I needed a computer with a native RS-232 port 3 years ago. The ordeal surrounding making this old computer useful right now can be another post entirely.

  Here’s what the monstrosity looks like thanks to characteristically short IDE cable lengths :

  
  

  

  Click for larger image

  
  

  Process :

  1. Turn on Xbox first
  2. Turn on PC

  Doing these things in the opposite order won’t work since the kernel really wants to see the drive when booting up. Inspecting the 'dmesg' log afterward reveals interesting items :
  

  <br />
hdd: PHILIPS XBOX DVD DRIVE, ATAPI CD/DVD-ROM drive<br />
hdd: host max PIO5 wanted PIO255(auto-tune) selected PIO4<br />
hdd: UDMA/33 mode selected<br />
[...]<br />
hdd: ATAPI DVD-ROM drive, 128kB Cache<br />

  Why is that interesting ? When is the last time to saw disk devices prefixed by ‘hd’ rather than ‘sd’ ? Blast from the past. Oh, and the optical drive’s vendor string clearly indicates that this is an Xbox drive saying ‘hi !’.

  Time To Read
  When I first studied an Xbox disc in a normal optical drive, I noticed that I was able to read 6992 2048-byte sectors — about 14 MB of data — as reported by the disc table of contents (TOC). This is just enough data to play a standard DVD video animation that kindly instructs the viewer to please use a proper Xbox. At this point, I estimated that there must be something special about Xbox optical drive firmware that knows how to read alternate information on these discs and access further sectors.

  I ran my TOC query tool with an Xbox Magazine demo disc in the optical drive and it reported substantially more than 6992 sectors, enough to account for more than 2 GB of data. That’s promising. I then tried running 'dd' against the device and it was able to read… about 14 MB, an exact quantity of bytes that, when divided by 2048 bytes/sector, yields 6992 sectors.

  Future (Past ?) Work
  Assuming Google is your primary window into the broader internet, the world is beginning to lose its memory of things pertaining to the original Xbox (Microsoft’s naming scheme certainly doesn’t help searches). What I’m saying is that it can be difficult to find information about this stuff now. However, I was able to learn that a host needs to perform a sort of cryptographic handshake with the drive at the SCSI level before it is allowed to access the forbidden areas of the disc. I think. I’m still investigating this and will hopefully post more soon.

• Imagick refresh

  25 septembre 2013, par Mikko Koppanen — Imagick

  After some hiatus I’ve been getting back on fixing bugs on Imagick and getting the code into more representable condition. This hiatus has been a result of busy work schedule and getting a new start-up running in Kuala Lumpur.

  While fixing a bug related to clone keyword I came across the following resource : http://www.rubblewebs.co.uk/imagick/. The page contains quite a nice collection of Imagick operations and is definitely worth checking out.

  On the other news, the development has been moved to Github. As I’ve been the most active developer of Imagick in the past years I decided to move the code to Github where rest of my projects are located : https://github.com/mkoppanen/imagick. For the past few days there has been quite a lot of development, mainly working on removing the excessive use of macros in the code to make things more readable and debuggable. This might be a good place to give thanks to Remi for fixing quite a lot of compile warnings and raising bugs regarding Fedora Packaging Policy. Most likely there will be a couple of beta releases in the near future.

  As mentioned in the previous post Windows builds are now available via http://windows.php.net and my builds provided here should be considered obsolete.