OpenShot
'Save Frame' does not render to expected preview when multiple resized images are overlayed
Description I resized 2 images 'A.jpg/B.jpg' and tried to overlay these resized images to a backgound image 'BG.jpg' in openshot. When saving the final frame, the exported frame (*.png) is unexpectedly minimized and so does not represent the image in the preview. It can be easily reproduced, I got it after playing around only 1h with openshot 3.3 (portable)
Steps to reproduce the behavior: (attached project and exported frames for reference)
- Put all 3 images in a row and resizing A.jpg/B.jpg, BG.jpg keeps unchanged (frames 172/478/780) -> OK
- Overlay BG.jpg independently with resized images A.jpg OR B.jpg (frames 1257/1589) -> still ok
- Overlay BG.jpg with BOTH A.jpg AND B.jpg (frame 2134) -> BROKEN, unexpected, does not represent the rendered image, much too small, in other experiment kind of broken
Expected behavior: The exported frame should alway represent the preview in all details
System Details:
- OpenShot Version [3.3]
Log Files:
Exception / Stacktrace:
Screenshots: Attached the screenshots and project file
Hello @matthimue. I am trying to replicate your issue but not having luck following your steps. Thank you for the *.zip file with all your content.
In your title you say ""Save Frame" does not render....". Are you talking about the "File | Save Current Frame" option?
-
Put all 3 images in a row and resizing A.jpg/B.jpg, BG.jpg keeps unchanged (frames 172/478/780) -> OK What does frames (172/478/780) mean? Where are you getting these frame numbers from? What are you trying to convey?
-
Overlay BG.jpg independently with resized images A.jpg OR B.jpg (frames 1257/1589) -> still ok
-
Overlay BG.jpg with BOTH A.jpg AND B.jpg (frame 2134) -> BROKEN, unexpected, does not represent the rendered image, much too small, in other experiment kind of broken
Not seeing what is "BROKEN".
I see the *.png files you included in your shared content. Can you please be a bit more specific as to what I should be looking at and what is exactly "BROKEN"?
Thank you!
Update: Nevermind the frame numbers and such. I see the markers where the frame numbers match, and the fact that you are using the "Save Current Frame" (SHIFT+E) option.
I am able to replicate your issue in v3.3.0. v3.4.0-Release-Candidate fixes this issue.
- Go to openshot.org/download/#daily and download the latest v3.4.0-Release-Candidate available.
- Instlall it and start it.
- Open your project and retest your 3rd scenario (frame # 2134).
OOps didn't see your last comment .... I'll try to use 3.4, is it available for windows too, Currently i use the portable version...
- Yes, I meant save Current Frame
- Look at the saved 'frame-0 2134.png' (screenshot included in _BUG), the 'exported frame' is in the minimized version in the top/left corner, even the background is minized. This is not what I see in the preview at the acc. marker, where the image fills up the screen.. So 'BROKEN' is basically 'why is it minimized, it should not' (?)
- I opened bug.osp and exported again at frame 02134, it shows up again in minimized version (still 3.3)
I double checked with "OpenShot-v3.4.0-release-candidate-14797-a7dfc596-0b018e34-x86_64.exe" on WIN11.
It does NOT fix the issue still get the frame in minimized form on 02134
Hmmm...it is working for me just fine. Let's give this a try.
- Close OpenShot if running.
- Uninstall OpenShot via Add or Remove Programs.
- Make a backup of c:\users\username.openshot_qt folder.
- Delete ....openshot_qt folder.
- Install v3.4.0-rc build #14797.
- Open your project and try the "Save Current Frame" again at frame 2134.
- If this worked, great, if not...continue to step 8.
- Delete those clips (the 3rd set) and redo it.
- Save your project.
- Now perform the "Save Current Frame" again at frame 2134.
Hi, i was able to create the frame now with v3.4.0-rc build #14797 and cleared everything before, BUT BUT ......
There is definitely still an issue. I continued to play around to make sure everything is fixed. I attach 2 frames which I exported @2210 without changing the position of the cursor, just changing the zoom with the mouse (shift+scroll) and save same frame again. I reproduced with saving at different frames, I still got strange behaviour, after that program crashes.
I added the screenshots for reference for 2 frames @2210, and also the log file. You might want to reproduce the issue by selecting different frames and saving the frames after you changed the zoom level.
Hello @matthimue Glad v3.4.0-RC worked better for you.
I am seeing the crash as well. However, I am not able to consistently reproduce it. Are you able to consistently reproduce it? If yes, please provide the exact steps you are performing. Don't leave any details out. Without making it happen concistently, it will be very challenging for the lead developer to debug and fix.
Update: The Zoom function has nothing to do with it. I am now able to reproduce the crash. All I needed to do was to Start OpenShot, drag an emoji onto a track, then "Save Current Frame" at different locations on the emoji clip, and OpenShot will crash. It takes at least 6-8 times of "Save Current Frame", and sometimes more but eventually, a crash will happen.
Note that I am unable to reproduce this in Ubuntu 25.10. Only in Windows. I have submitted a ticket for the lead developer to look into this. Not going to be a high priority but is in the queue.
Hi, good to know that I'm not the only one seeing that issue ...for me it's the same, it was not always reproducable...... if I'm able to always reproduce it, I'll let you know. As a developer myself (although not having the experience to really help here :-(), I know how important this is.
What really worries me about the issue is, looking at the strange output from saving frames with wrong sizes, why could this happen at all. Why seem the rendered preview be correct and the single frame to be exported sometimes so weird (hope you could verify this too ?). This would have been my starting point, where does the data and strange behaviour could come from that causes these outputs ... could this be an indicator of a root cause.... may has impact on other issues too (?)
Hello @matthimue I am not able to verify a single frame export being "sometimes so weird". So, since it only happens sometimes, other times it is fine. Please elaborate what you mean by "weird" so I can understand the issue better.
Ok, weird is not really technical, agree. Please compare 'Frame-02210.png' and 'Frame-02210-2.png' in _BUG2.zip, you should easily see what I mean, Frame-02210.png is weird, having the background twice, big and small, not matching the preview window at all, How can this happen, there must be an answer for this. Note : It's taken from the same frame, not moving the cursor, just stretching the timeline. I already described this. Play around a bit, you should get too. In the original _BUG.zip it's the Frame-02134.png, which is weird, why is this that small. have a look at this too.
Hello @matthimue I see the issue now and able to reproduce it. I am doing some more testing to gather more information to provide to the lead developer.
You are correct, it is "weird"...LOL!
Hi, so I think I found a way to always reproduce the issue with even 3.4 and _BUG.zip I think all has to do with mess up of cache handling.
- clean up .openshot_qt, unzip the project _BUG.zip, open the project, confirm cache default settings (0,3 behind/ 0,7 ahead of current position)
- Here is the first point I wonder, although at this point not yet directly related
- when moving the cursor right, looks like the cache bar follows in the default ratio setting 0,3/0,7 --> expected, OK
- when moving the cursor left, cache bar follows cursor movement after reaching left boundary only-- NOT EXPECTED, BUG(?), should always follow acc. to ratio setting 0,3/0,7 not stick to 0,0/1.0 when moving left
- when clicking somewhere on the timeline out of the range of current cache bar, cache is not set to default ratio setting 0,3/0,7 --> NOT EXPECTED, BUG(?) I wonder why the blue bar indicating the cache span always start at the cursor now meaning 1,0 ahead, when clicking somewhere
- Now save frame 02134 -> OK, although observed here that when saving a frame cache is always recalculated in a way starting at the frame that is saved -> NOT EXPECTED, BUG? why does the cache being recalculated and repositioned when saving the frame?
- Now the issue to reproduce!. I only change the cache ratio to be 0,1, or even 0 in the preferences. When I now save the frame again, i see the 'weird' minimized Frame-02134 --> NOT OK, this is the confirmed BUG that we're talking about
- I try to change back the default ratio to 0,3/0,7 in the preferences and save the frame again --> cache setting seem to not being applied, it is still represent the 0,1 setting, what has been set in 4. --> NOT EXPECTED, BUG?
- restart the application, now the ratio is setup again, saving the frame 02134 is still weird, minimized --> NOT EXPECTED, BUG?
- clean up the folder '.openshot_qt' and starting the application again with default setting, saving frame 02134 --> OK again
So from my point of view, looks like the issue is related to a broken cache handling.
- My question is, why is the cache not always centered around the cursor acc. to the settings in the preferences dialog when moving left OR right?
- Why will the cache being recalculated and now start at the frame being saved? Is the frame taken from the cache, before/after recalculating ?
- Why can't I change the cache setting (behind/ahead) in the preferences without restarting the application and for correct operation need to clean-up the folder .openshot_qt.
- I think it could be useful if there is a clean way to disable the cache, to test with, ...... at least could have been useful for debug like this issue
A lot of issues acc. to what i tested related to the cache, but at least for me the bug is reproducible this way and therefore assuming being related to messed up cache handling
Thank you @matthimue for all this information. The Cache question is beyond my expertiese and requires the lead developer to respond. The Cache is going through much enhancements (going on for at least a year+) now. However, with some of the code limitations, it's taking longer since the lead developer is making some major architectural changes. Hopefully that will facilitate improvements of the Cache efficiency and performance.
I think for now we have plenty of information in the queue for the lead developer to work on to debug and hopefully resolve this issue.
Thank for you help, I think it's always important having someone who is able to reproduce things. So basically my summary is, could it be that when saving a frame@x, the cache is always triggered to be recalculated starting @x first? The 1st frame maybe considered as a cornercase with additional/special calculations that sometimes also cause crashing the program.
Let's see if we get some good news here :-)
Hello @matthimue This issue has been resolved in the latest v3.4.0-Release-Candidate. Please download from openshot.org/download/#daily and install it.
Feel free to close this if all is working well now.
Hello, the issue is still there and reproducible with 'OpenShot-v3.4.0-release-candidate-14841-94fab000-0b018e34-x86_64'. So I can not close the issue.
I'm referring to the project '_BUG.zip' attahed at the beginning of this issue.
I could reproduce the issue, although it's not exacly the same (frame 2134 was ok this time). But the issue is still the same, it's related to screenshot taken with 'weird' output.
I attached 3 times the picture that I reproduced with following steps after installation of mentioned release:
- clear '.openshot_qt' to always start at same point with default settings
- Step to frame 2174 (don't know a better way, or maybe this way is necessary, at least this reproduces the issue,...) skip playhead 6 times along the markers to last frame 2134 then step the playhead with the cursor on the keyboard 40xtimes to end @frame 2174
- save frame 2174, you should get a picture that is even more weird than the previous ones (see attachment for all 3 runs)
So try yourself. Looks something basic is still broken seriously.
Hello @matthimue Thank you for the quick response. I'll work on this today to reproduce your steps and then report back to the lead developer.
Hello @matthimue Please retest and try something for me:
- Open your project.
- Drag an emoji from the Emojis tab onto Track 3 passed the last clip you have on the track. Approximate around the 1:30 time.
- Now perform the SHIFT+E (Save Current Frame).
Let me know how this worked.
A more recent v3.4.0-Release-Candidate-14843 was just released and it fixes this issue. It was related to the Cache rebuilding.
Please test and confirm.
Don't know what your expectation was with the 'Emoji'-test (?). I did not encounter any issue in both releases '....14841....' and '....14843.....' I retested my issue with the latest '....14843.....', and yes, I could not reproduce the issue anymore. So for now, I close the issue. Thanks for all help here!
Don't know what your expectation was with the 'Emoji'-test (?). I did not encounter any issue in both releases '....14841....' and '....14843.....' I retested my issue with the latest '....14843.....', and yes, I could not reproduce the issue anymore. So for now, I close the issue. Thanks for all help here!
The "Emoji" test was to confirm that adding was forcing the Cache to rebuild thus eliminating the issue. However, and as you reported, the issue has been resolved.
Good luck with your project(s).