View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000505||Cinelerra-GG||[All Projects] Bug||public||2020-09-06 18:55||2020-09-30 23:54|
|Platform||Intel 64GB RAM,||OS||Fedora||OS Version||32|
|Target Version||Fixed in Version||2020-09|
|Summary||0000505: Corrupt aspect ration on .png image scanned with camera to get scrolling credits|
|Description||I use a png file 1280x????? (very long) at the end of my track to generate scrolling credits using the camera to scroll the image.|
I create the .png file from an .odt libreoffice doc to pdf to png using gimp. The png file aspect ratio becomes corrupt if I do almost anything at all to the track. Even with the track un-armed. Closing cin and re-opening causes the corruption always.
Simply closing cin and re-opening causes the problem.
The fix is to rebuild the index on the png file. I do not have to arm the track or do anything at all other than simply to rebuild the index. This fixes the problem until the next time I do any editing (even to another track) or close cinelerra and reopen.
I have built cin from the git master with the same results. This bug has been here for many versions (perhaps years).
This problem makes it impossible to render using batch jobs as the credits are 100% always with corrupt aspect ratio.
|Steps To Reproduce||Do almost anything, even with all tracks disabled. |
Close cinelerra, then re-open and the .png file at the end has corrupted aspect ratio.
This is not an intermittent problem. It happens constantly with all versions of cinelerra including the current master from git.
|Additional Information||I probably would be able to trap the problem with gdb given some instructions on how and where to look.|
|Tags||aspect ratio, bug, corruption, still image|
|Change is in the September builds so closing.|
Thanks to you and your demo this issue is fixed -- we would never have been able to ascertain the problem without BugTest1 (which we have now deleted off of our computer as promised). So glad you took the time to report this and follow up -- now it is fixed for everybody!
I've gone through a lot of my projects that had always failed and the current git master version fixed my problems in all of them.
Thank you very much. I'd been fighting this for years.
As far as I am concerned the issue closed. Looks good.
An update for the benefit of others:
- The aspect for width AND height was increased to 32767. If you load a file more than that, an error message will be produced.
- @shipman provided a demo file for GG that always produced the error so he was able to check to verify the fix and meanwhile Shipman found another problem that has now just been checked into GIT (it was an Alpha problem).
- In addition, an error message will be produced if using OpenGL when it goes to 16384 or over because it does not handle that (with texture, I think) so that the user can switch to Settings->Preferences, Playback A, Video Driver of X11 (software).
Waiting to hear back from Shipman to confirm all is now fixed.
We checked into GIT, the increase from 10000 to 32767 for the height.
I was supposed to update this but did not get it done. Neither GG nor I could reproduce what you see BUT we did determine for sure that the 1920 x a very large number could ONLY BE as large as 10000 as coded. GG has now increased this to 30000 (I will have to check the exact number) but it has not been checked into GIT yet. I started making a demo with the Titler showing what we tried and it did not scale incorrectly for us but again I could not get it done. It would probably be helpful if you could send us a small session file that demos the problem (probably along with a png that creates the error). You can send privately to me and we will not share at [email protected].
I can build cinelerra and test anything you come up with. I'm guessing that it is just a variable that is getting overflowed somewhere.
This is very easy for me to reproduce.
|I just thought that possibly the problem happens because the aspect ratio of my .png file is not the same as the track format. My track format is 1920x1080, the aspect ratio of my .png file is 1920 x (a vary large number like 36000). I don't have a problem doing Ken Burns effects on still images that match the aspect ratio of my project.|
|Thank you for reporting and with sufficient information for us to understand the issue. We will attempt to look at this today. And also it is very helpful to know that this has been happening for years. Rebuilding index files is a good idea but maybe we can find a way to alleviate the batch file problem.|
|2020-09-06 18:55||shipman||New Issue|
|2020-09-06 18:55||shipman||Tag Attached: aspect ratio|
|2020-09-06 18:55||shipman||Tag Attached: bug|
|2020-09-06 18:55||shipman||Tag Attached: corruption|
|2020-09-06 18:55||shipman||Tag Attached: still image|
|2020-09-06 19:11||PhyllisSmith||Assigned To||=> PhyllisSmith|
|2020-09-06 19:11||PhyllisSmith||Status||new => acknowledged|
|2020-09-06 19:11||PhyllisSmith||Note Added: 0004002|
|2020-09-06 19:58||shipman||Note Added: 0004003|
|2020-09-12 05:39||shipman||Note Added: 0004014|
|2020-09-12 13:15||PhyllisSmith||Note Added: 0004015|
|2020-09-12 13:18||PhyllisSmith||Note Edited: 0004015||View Revisions|
|2020-09-12 15:29||PhyllisSmith||Note Added: 0004016|
|2020-09-13 01:25||PhyllisSmith||Note Added: 0004017|
|2020-09-13 01:25||PhyllisSmith||Status||acknowledged => feedback|
|2020-09-13 04:26||shipman||Note Added: 0004019|
|2020-09-13 04:26||shipman||Status||feedback => assigned|
|2020-09-13 15:46||PhyllisSmith||Status||assigned => resolved|
|2020-09-13 15:46||PhyllisSmith||Resolution||open => fixed|
|2020-09-13 15:46||PhyllisSmith||Fixed in Version||=> 2020-09|
|2020-09-13 15:46||PhyllisSmith||Note Added: 0004021|
|2020-09-30 23:54||PhyllisSmith||Status||resolved => closed|
|2020-09-30 23:54||PhyllisSmith||Note Added: 0004091|