Yeah, I reckon the problem would be right at the beginning:
<a.+?href\s...
The problem is that there's nothing to stop .+? from matching href - so if the first <a> tag isn't being followed by <img, then the regexp engine will try again by having .+? match everything up to the next href. (The original expression would match only single tags, without regard for what they might be followed by.)
This can be solved in a manner that allows preg_match to shine out over ereg - because PCRE regexps allow you to assert that certain patterns must not be matched (href in this case) - but there is a much simpler solution in this particular instance...
The problem with the overenthusiastic match is that it runs on past the end of the <a> tag, and on into the following text in pursuit of that <img. Now the crucial feature of any tag is that it starts with < and ends with >. So if we match a > we can pretty much safely assume we got carried away. In other words, we're happy with that part of the expression matching anything else, but not that.
So if we were to replace .+? with [>]+, it will happily match characters only so long as it doesn't go past the end of the tag. There are other places where this would be needed (near the start immediately after <img, for instance). There's actually already an instance of this near the ends of both tags (where it says [>]* as short for "the rest of the tag". The bit in the img src= attribute would be [.]+ (is there any particular reason why you only want to match tag pairs with certain file extensions?) and ... um, reckon that might be about it.