preview doesn't scale

[Raffaella Traniello]

The preview windows shows the image in real size.
This is not a problem until your image resolution gets close to your screen resolution.
In that case the preview is cropped, only part of "canvas" is visible and it is impossible to prepare the frame to shoot.

Tested it on a laptop with a 1366x768 resolution screen and three input devices:
- Canon EOS 60D SLDR camera (1056x704 live view) - screenshot attached
- Logitech Quick Cam Pro 9000 webcam (1200x720)
- Manually imported pictures (5184 x 3456)

In the attached screenshot it is clearly visible that the captured image (4:3) is bigger than the previewed one (cropped to 16:9, like the screen). Pay attention to the white top/bottom borders: they are visible only in the captured image.

[Graham Evans (gray-karricountry)]

The other time this is a problem is when the capture resolution is small compared to the monitor resolution so your preview frame is too small to see properly. Eg when I use my usb capture device to get a 'live view' stream off my digital camera which is then previewed on a 1920 by 1200 monitor. My liveview stream is something like 640x320 px. The 1:1 preview becomes a thumbnail.

For this case the workarounds are to change the resolution of the monitor (of course this will lead to non-native resolution and mean the stopmotion widgets all get clunk and crammed in).

Another non-satisfactory workaround is to use a compositing window manager with a zoom program. There are a fair range of screen zoom options so perhaps one of them would be a good choice.

[Herman Robak (herman-skolelinux)]

I'm starting on a fix, in two different places:

One is to replace SDL's JPEG loader with a customised one. Libjpeg lets you specify output sizes that are power-of-two fractions of the original: 1/2, 1/4, 1/8. This makes decoding faster, and saves RAM. No expensive downscaling. Cons: JPEG only, and not a snugly fitting image size.

The other is to use OpenGL for display, where scaling is done in the GPU. Cons: Not available on all computers, and huge images may be a problem.

I considered switching to SDL YUV overlay for display, which would require a total rewrite of the diff/mix function. That part needs rewriting anyway, for performance reasons, and I want to do that. But what about RGB native formats then? I don't think we can burden Stopmotion with multiple internal colour formats, a la Cinelerra. Not soon, anyway.

Another thing: Stopmotion should try to resize the window to give enough room for a 1:1 image, if the screen is big enough. This is lower hanging fruit, but it will not be enough. Failing that, it could provide scroll bars. We'll have time to try out some options before next developer sprint. :-)

[Herman Robak (herman-skolelinux)]

I have found how to force a resize to at least big enough for 1:1 display (suitable for the current SDL-based frameview).

The OpenGL re-implementation of the frameview is almost done. It scales when you resize the window, and maintains aspect ratio. Mix and diff onionskinning has been mostly re-implemented in OpenGL. Mix mode gets only one trailing frame so far, not up to five. But it's the _right_ frame; the active frame, not the previously _captured_ frame. Bonus feature: Rotate display 180 degrees.

[David Sterratt (david-c-sterratt)]

This bug is affecting me (and the epic LEGO animation my son and I are working on :-) and I was wondering if you'd managed to get either the OpenGL or SDL methods going. Thanks for all your work on the program.

[D. L. Yonge-Mallo (dlyongemallo)]

Any updates on this?

[Tim Band (tim-band)]

Released in version 0.8.2