The problem with supersampling does seems to be computer related. I could make a movie with supersampling in another computer. The graphic card in the problematic computer (Running Windows XP) is an: ATI Radeon HD 2600 Pro AGP Driver version: 8.410.0.0 Are there known problems with this graphic card /driver? . Any solution ? I noticed that in the computer that I could make the movie the image changed size as each frame was being recorded (as expected when using supersampling). However, this did not occur in the computer that produced the bad movie. The script I am using to make the movie looks now like this: reset p0 movie record supersample 3 #movie record wait 25 reset p1 1 wait reset p2 1 wait reset p3 1 wait reset p4 1 wait reset p7 1 wait reset p8 1 wait reset p9 15 wait 25 wait reset p10 1 wait reset p11 1 wait reset p12 1 wait reset p13 1 wait reset p14 1 wait reset p15 1 wait reset p16 1 wait reset p17 15 wait 25 movie stop movie encode output Test.avi mformat avi bitrate 10000 #reset p0 Another question. Do I need to put a wait command after each reset command ? Thanks Hernando Tom Goddard wrote:

Hi Hernando,

Your example script contains no "wait" command so I'd expect the resulting movie to have 0 (or maybe 1) frame. Not sure how that could work with or without the supersample option.

Here's a recent movie making tutorial with plenty of examples of the "wait" command.

http://www.cgl.ucsf.edu/chimera/tutorials/movies09/moviemaking.html

I guess you know the above if you get correct movies without the supersample option. So your problem sounds like a bug in supersample image saving. If you use File / Save Image with supersample 3x3 is the resulting image correct? If not you should use Help / Report a Bug... to report the problem, and attach the incorrect image. We have changed how image saving workings so that it does not capture directly from the screen (that old method had problems with overlapping windows appearing in the image). The new code in daily builds may have bugs or it may be a problem with your graphics driver.

I tested the May 25 daily build on a Mac and it correctly recorded a supersampled movie using a script like yours with "wait" added before "movie stop".

Tom

hsosa@aecom.yu.edu wrote:

...

When using using supersample > 1 to record a movie the movies are not saved correctly (black or random color images) In the command script below the saved movies are OK if the option supersample 3 is eliminated and wrong if included.

reset p1 movie record supersample 3 reset p2 reset p8 10 movie stop movie encode output test2.avi mformat avi

I'm I doing something wrong ?.

I'm running the daily build version of Chimera (May 25).

Thanks

Hernando

-- ----------------------------------- Hernando Sosa Dept. of Physiology and Biophysics Albert Einstein College of Medicine 1300 Morris Park Av. Bronx NY 10461 phone (718) 430-3456 FAX (718) 430-8819 email hsosa@aecom.yu.edu -----------------------------------

Hi Tom, Saving a single image is also problematic even without supersampling. When using supersampling (3x3) sometimes I get a garbled images without error messages and most of the time some error message appears. I used the report bug button the one time that this dialogue appeared. I also got some pythonw.exe error that forced me to exit chimera I attached some of the garbled images saved (either black or colored squares). If I start chimera, as you suggested, with the pbuffer option dissabled (using the Debug OpenGL feature) then I can save images with or without supersampling. Thanks Hernando Tom Goddard wrote:

Hi Hernando,

The computer that worked was using the old image capture technique -- you see it displaying tiles of the full image when supersampling is used. If you were using a current Chimera daily build then it didn't use the new off-screen image saving method because the graphics driver didn't support OpenGL pbuffers.

As I suggested in my previous message, try saving a single image (File / Save Image...) with supersampling 3x3 and see if it works and use Help / Report a Bug if it does not and attach the image. This may be a graphics driver bug or it may be a Chimera bug. If it is a graphics driver bug you can try updating your graphics driver

http://www.cgl.ucsf.edu/chimera/graphics/graphicsbugs.html

or disabling Chimera graphics features

http://www.cgl.ucsf.edu/chimera/docs/ContributedSoftware/debug/debug.html

Very likely disabling use of pbuffers will allow you to use supersampling.

Tom

hsosa@aecom.yu.edu wrote:

...

The problem with supersampling does seems to be computer related. I could make a movie with supersampling in another computer. The graphic card in the problematic computer (Running Windows XP) is an:

ATI Radeon HD 2600 Pro AGP Driver version: 8.410.0.0

Are there known problems with this graphic card /driver? . Any solution ?

I noticed that in the computer that I could make the movie the image changed size as each frame was being recorded (as expected when using supersampling). However, this did not occur in the computer that produced the bad movie.

The script I am using to make the movie looks now like this: reset p0 movie record supersample 3 #movie record wait 25 reset p1 1 wait reset p2 1 wait reset p3 1 wait reset p4 1 wait reset p7 1 wait reset p8 1 wait reset p9 15 wait 25 wait reset p10 1 wait reset p11 1 wait reset p12 1 wait reset p13 1 wait reset p14 1 wait reset p15 1 wait reset p16 1 wait reset p17 15 wait 25 movie stop movie encode output Test.avi mformat avi bitrate 10000 #reset p0

Another question. Do I need to put a wait command after each reset command ?

Thanks

Hernando

Tom Goddard wrote:

...

Hi Hernando,

Your example script contains no "wait" command so I'd expect the resulting movie to have 0 (or maybe 1) frame. Not sure how that could work with or without the supersample option.

Here's a recent movie making tutorial with plenty of examples of the "wait" command.

http://www.cgl.ucsf.edu/chimera/tutorials/movies09/moviemaking.html

I guess you know the above if you get correct movies without the supersample option. So your problem sounds like a bug in supersample image saving. If you use File / Save Image with supersample 3x3 is the resulting image correct? If not you should use Help / Report a Bug... to report the problem, and attach the incorrect image. We have changed how image saving workings so that it does not capture directly from the screen (that old method had problems with overlapping windows appearing in the image). The new code in daily builds may have bugs or it may be a problem with your graphics driver.

I tested the May 25 daily build on a Mac and it correctly recorded a supersampled movie using a script like yours with "wait" added before "movie stop".

Tom

hsosa@aecom.yu.edu wrote:

...

When using using supersample > 1 to record a movie the movies are not saved correctly (black or random color images) In the command script below the saved movies are OK if the option supersample 3 is eliminated and wrong if included.

reset p1 movie record supersample 3 reset p2 reset p8 10 movie stop movie encode output test2.avi mformat avi

I'm I doing something wrong ?.

I'm running the daily build version of Chimera (May 25).

Thanks

Hernando

-- ----------------------------------- Hernando Sosa Dept. of Physiology and Biophysics Albert Einstein College of Medicine 1300 Morris Park Av. Bronx NY 10461 phone (718) 430-3456 FAX (718) 430-8819 email hsosa@aecom.yu.edu -----------------------------------

On May 27, 2009, at 7:35 AM, hsosa@aecom.yu.edu wrote:

Another question. Do I need to put a wait command after each reset command ?

No, you don't have to. After every line of commands (which could be several commands strung together by semicolons) Chimera will wait one frame if the commands did anything that would change the display (and if there's no explicit wait command at the end of the line). So the only explicit wait commands you needed in your script were the ones that waited 25 frames. And it would have been better if it had been on the end of the preceding line (i.e. "reset p17 15; wait 25") or else you in fact get 26 frames since one frame will implicitly be shown after the "reset p17 15". --Eric Eric Pettersen UCSF Computer Graphics Lab http://www.cgl.ucsf.edu