Photoshop CS5 won't open a PNG pct exported from Quicktime

Question

I exported a move to still from Quicktime Pro, using the PNG compression settings, and when I try to open it in Photoshop CS5 I get the error message "Could not complete your request because the PICT contains data that is no longer supported in this version of Photoshop." Photoshop CS4 has no such compunction. And I was able to open them in CS4 and recompress them and get CS5 to open them, but this is really annoying. I often have to make screengrabs of Quicktime movies. Looks like I will have to do it staight from within Final Cut and not use Quicktime to do it.
I have included a still of the error message:
And a still of the Quicktime compression settings:

Answer 1

"I am curious. How can changing the the extension of a file format trick photoshop or software in doing something that it can not do.
I thought that it did not have the engine to translate the data. So what happens to a file by simply changing the extension. Is the data altered ?"
That's a real good question and something that's been a frustration since the introduction of OS X. Such behavior was never a factor in an Apple OS until Unix. Such nonsense was always part of Windows behavior. It seemed to me it was actually worse immediately after the transition from OS9 to OS X, then improved, now is very stringent again.
I have thousands of Illustrator files (suffix .ai). I have been working with several other vector programs lately, including Intaglio, a Cocoa product. Intaglio refuses to recognize a .ai file, although it is nothing but a plain text file with proper PostScript code. If I save the file out of Illustrator as an EPS file (suffix .eps) Intaglio has no problem opening it. The difference between a . ai file and the same image as a .eps is only a subtle change in some of the PostScript comments in the file, but nothing that really changes the graphic data. So why does the program give an error message with the .ai file that it is an Unsupported File type?
Even more perplexing, if I simply change the .ai suffix to .eps, Intaglio is perfectly happy with the file. It opens and displays perfectly. Nothing has changed in the file data by changing the suffix.
This kind of behavior seems to be an interaction between applications and the OS. The application calls the OS to perform certain functions and the OS demands a particular convention of the file name, or it sends back an error message and the application stops at that point.
Have you noticed that the OS asks if you really want to change a file name suffix? That's how insistent it is that the name be a certain type.
TextEdit is a program with no graphic capabilities. If I try to open a PostScript file with it, it balks. (I don't want it to display the graphic page layout - I want to edit the content of the file) A PostScript file has mostly plain ASCII text that can be read and changed by anyone who is familiar with PostScript. (There also can be some long streams of binary image or font data. Such data can't easily be edited, but a programmer could locate it, remove it, or move it around in a text editor program). TextEdit will not open a .ai or .eps PostScript text file as text, unless I change the suffix to .txt. Older (OS9) editors have no such problem and other "programmer editors" ignore the suffix also.
Programs should (and can) open and display (or reject) files correctly by the nature of the data in the file without any need to examine the file name.
Apparently, some applications (Graphic Converter?) have decided to ignore the file name nonsense and deal with the actual file data, as they should just like OS9 and previous Mac Oses did. But OS X "conforming programs" insist on the strict Unix way of doing things.
I have always felt there was some kind of passive-aggressive, arrogant insistence on this by the Unix/NeXT programmers who came with Steve Jobs when he returned to Apple. Early NeXT/OS X implementations of the Mac Desktop were very un-Mac-like and were eventually changed after howls of protest from the Mac community. But they never relented on the file suffix thing, apparently insisting that the human-readable file name was critical to the machine's understanding of the file type.
All this nonsense is unnecessary as the very simple workarounds prove and very inconvenient for the user. There's just finger pointing and standing on principle and insisting on adherence to some pedantic specification, rather than operational effectiveness.
Rich