So, this seems to work mostly as intended, although the default behavior on macOS with a Retina panel can be confusing.
-
Remove the call to PsychImaging(‘FinalizeConfiguration’); in your script, as that is wrong usage and also essentially never needed. It is one of these “use only if you really know what you’re doing and have very special needs” functions. If you remove that call then the warning about “unfinished configuration phases” will go away which PTB prints each time your original script runs. More importantly, now the ‘UseRetinaResolution’ request gets honored, the rendering pipeline gets configured for the full native Retina panel resolution, and proper high resolution movies get written out.
-
If you don’t request ‘‘UseRetinaResolution’’, or have that bug in your script that causes ignoring all PsychImaging() requests, then the panelfitter will be enabled to give you a quarter size virtual framebuffer for drawing, and it upscales that content during ‘Flip’ to the full native panel resolution. This is the backwards compatible behavior to non-Retina Macs, as it emulates what earlier macOS would do for non-Retina-enabled applications. In practice you’ll get a 1440x900 pixels virtual drawbuffer size for a physical 2880x1800 pixels Retina panel, ie. half the horizontal and vertical size of the real display.
Here’s where the fun starts. You don’t specify the desired width x height of your movie frames in the call to ‘CreateMovie’ in your script, so the function has to guess a reasonable size and it chooses the “size” of the onscreen windows drawing buffer, ie. the same size as reported in the ‘windowRect’, or by Screen(‘Rect’, window) etc., because that’s what one would usually expect. In my example that would be 1440x900 pixels. This will define the size of the rectangle that gets screen-captured and written out into the movie. The ‘AddFrameToMovie’ function can take screenshots from different buffers, and if one doesn’t specify which buffer to screenshot from, it will default to the OpenGL frontbuffer, ie. what gets physically shown on the display right now. On Retina panels on macOS in this compatibility mode, in my example the back-/and frontbuffers are full size 2880 x 1800 and so the chosen size for screen shots for your movie is only 1440x900 vs. 2880x1800 and so you only capture one quadrant of the image.
The way around this is to specify ‘drawBuffer’ as the buffer to capture, e.g.,
if mType == 1
Screen('AddFrameToMovie', window, [], ['drawBuffer'], moviePtr);
elseif mType == 2
Screen('AddFrameToMovie', window, windowRect, ['drawBuffer'], moviePtr);
end
Now the drawbuffer with size 1440x900 gets captured and all is good - but lower than Retina resolution. This captures what your script has drawn, with the catch that you’d have to put the AddFrameToMovie call before the ‘Flip’, because otherwise that drawbuffer will have been cleared to background color after ‘Flip’. The default of capturing the ‘frontbuffer’ will give full resolution currently displayed image, a setting of ‘backBuffer’ would give the full resolution image that will be shown after next ‘Flip’, with all the image processing operationg of the imaging pipeline applied, e.g., geometric distortion correction, color conversions, stereo modes etc.
Or you specify the wanted size of the movie frames in the ‘CreateMovie’ call, so no guesswork by the software wrt. to wanted movie sizes etc. is needed.
But the most simple solution for bog standard use cases is just to remove that wrong ‘FinalizeConfiguration’ call and get movies in full Retina resolution.
There seems to be one bug though specific to macOS Retina handling, if one leaves everything at default settings and doesn’t use ‘UseRetinaResolution’, like in your original script: That is that both your mType 1 and 2 should both capture the top-left quadrant, iow. mtype 1 should behave like mtype 2, which it doesn’t. I guess i’ll see if that can be fixed in some future release, once somebody pays for the bug fix.
Btw. if you look at ImagingStereoDemo.m’s CreateMovie call, you’ll see those optional ‘CodecSettings…’ parameter. That changes the encoding parameters to something that not only higher quality movie playback software like Psychtoolbox/GStreamer or VLC can play back, but also the more primitive/limited QuickTime player of macOS or whatever MS-Windows calls its media player. Worth a try if you don’t need highest quality and want to simplify your life.
-mario
[Work time for this investigation on a MBP 2017 with macOS Catalina so far: 3.5 hours. For other readers of this response: The only reason this was investigated for free by myself is as a thank you to Peter for making all those nice tutorials. For a regular user, this investigation would have been a paid support request, costing them 1050 Euros + sales tax, unless discounted for labs who already have a long running paid support membership, as any lab should have.]
