SVG files not rendered properly #1081
Comments
|
@N3WWN - Wow, this is an example of a really great bug report! O_O Thanks a million! |
|
Hi |
|
@donkikhot - Good sir, Openshot 1.x series is no longer under development. Perhaps you should try the 2.x series out. @N3WWN - Wow. That's a really good report. 👍 |
|
Ok, thanks. |
|
@donkikhot - I will try to bring the developer's attention to this, too. Hopefully, this will be fixed soon. I hope you keep on supporting OpenShot and do report any issues as they arise. Thanks! :) |
|
@DylanC - Can you confirm this, cap'ain? I am not that good with InkScape. Perhaps this ought to be put in the check list for v2.4.2? |
|
Didn't work for me either titles_model:INFO updating title model. |
|
Thank you for the confirmation. Are you using the latest daily build? Does it render incorrectly or are you unable to import the svg file at all? o.O |
|
@peanutbutterandcrackers - Maybe consider this for the checklist. |
|
@DylanC - The checklist has been updated, Cap'ain! |
|
FYI, I'm working on resolving this right now. It will hopefully be my next PR for this project. |
|
Awesome! I am looking forward to the PR! :) |
|
OMG! I can't believe I messed up the PR for this! I somehow PR'd zero changes back into my dev branch instead of here. At any rate, would @peanutbutterandcrackers , @DylanC , @ferdnyc and/or @jonoomph take a look at my changes and do a quick sanity check on them: OpenShot/libopenshot@master...N3WWN:resvg_rendering I'll remove the lines with my initials ( There will need to a change to Basically, if the image file has an
Feedback welcomed for this change before I submit the PR so I can fix any problems beforehand. Thanks! |
|
Hmm, seems I can't comment on that branch as it's not a pull request. That's fine, here works. I haven't tested the SVG changes yet, but I will try to. But if there are rendering issues with the current lib, and resvg fixes them, then changing over sounds sensible. Thanks for doing the work to find an alternative. I'm a bit concerned that That aside, one minor nit: I'd suggest submitting OpenShot/libopenshot@16b9cd9 as a separate pull request from the rest. I'm curious to see how it affects the logging output, but on first glance it looks like a good change to me. If I'm interpreting correctly it's totally unrelated to the SVG rendering changes, though, yes? Better if each logical change stands alone in its own PR, and can be evaluated on its own merits. |
|
I subsequently (and accidentally) deleted the comment that referenced this issue, but I'm glad the link stayed here because I ended up tossing a bunch of inline comments at the commit, which can be seen by following the "ferdnyc referenced this issue..." link above. They don't show up inline if you follow @N3WWN 's link (though I now see they're collected at the bottom of the page), because I didn't have permission to add inline comments there. For some reason! (That reason being: Github is confusing.) I looked into resvg a bit more. It's distributed under the Mozilla Public License 2.0, which is good because that's considered a GPL-compatible license and is permissible for packaging in Fedora and most likely other libre distros as well, unless the license user has explicitly chosen to make it incompatible (which it doesn't appear RazrFalcon has). Surprisingly enough, though, it appears that nobody has even proposed its inclusion in the Fedora packaging system. ...Actually, I guess that's not so surprising when you consider that it's only even been available on Github since December 18. Yes, of last year. This thing is really new, and OpenShot would likely be the impetus for its inclusion in many distros. That's not necessarily a bad thing, assuming it's mature and stable enough to meet our needs, and using it solves problems. I was hoping that perhaps the rendering issue was caused by older AppImage versions of QtSVG, but after building the Qt svgviewer example project under Qt 5.9.4 and using it to load both of the sample (It probably makes sense, for their purposes, that Qt is targeting SVG Tiny 1.2 with QtSVG, as that's explicitly "a profile of SVG intended for implementation on a range of devices, from cellphones and PDAs to laptop and desktop computers" and Qt is very focused on mobile-platform support these days. But it does mean that if we want to incorporate arbitrary files from a full-featured editor like Inkscape, it's probably not going to be up to snuff. QtSVG is meant, it seems, to work with SVG files which have been designed with the intent of using them in Qt applications, and therefore can avoid coloring outside the lines of SVG Tiny 1.2.) |
|
@peanutbutterandcrackers writes:
Checklist? There's a checklist? Does this mythical checklist exist anywhere accessible to others? Seems like it could be a useful thing to have outward-facing. I know Github has the Projects feature for basically this purpose, though I've never used it myself. There's a Projects tab in the repo here, though currently the only thing it contains is an "ad" for the feature and a link to that doc. So I'm assuming @jonoomph or someone would have to enable access, before it could be used for anything. Still, even a Github issue containing the list would be a way to connect issues to it, sort of like a tracking bug in bugzilla. |
|
@ferdnyc - Here it is. It's just a humble little check-list. :) @N3WWN - I'm afraid I won't be able to test this out as I am working from a friend's computer even right now. But I'll try to see if I can. However, with @ferdnyc here and @DylanC, I think you have plenty of good testers. But awesome, good sir! You're amazing! |
|
[Checklist] Neato. Another question I can't believe I didn't think to ask until now: Do we know the status of resvg on Windows/MacOS? Has anyone (on their end, I mean) looked into building it for those platforms? If QtSVG is failing us, it's failing us on every platform, and whatever replacement we use should probably be used everywhere. I have no idea where resvg stands on that front, I'm honestly asking. Hopefully it's not a problem. If it's not going to be available on one of our platforms, though, I have to imagine that certain other options (librsvg in particular) should be fully cross-platform and should also solve these issues. (I can say that with a fair degree of certainty, since it's what ImageMagick uses for SVG support and ImageMagick (a) has excellent cross-platform support, and (b) had absolutely no trouble rendering the bug sample files properly when I used it to view them.) Really, any general-purpose SVG library should work; my understanding, having now looked into it more, is that QtSVG is not quite a general-purpose SVG library. Sorry to bombard you with these questions, @N3WWN , just thinking out loud. |
|
I looked into it. They have a build process for Windows and MacOS, so there hopefully shouldn't be any issues. It does mean that rust will need to become part of the OpenShot build environment on those platforms as well. (On Linux that won't be necessary, at least once distros have resvg already built and available as a packaged library.) They do mention that their Qt backend only "officially" supports Qt >= 5.6. It "should" work with any version, they handwave (prefaced with "Technically," to inspire maximum confidence), but this is another excellent argument for updating the version of Qt used for the AppImage build to something newer than 5.2.1. (IIRC Windows 2.4.1 uses 5.6.something, so that's good enough. I'm blindly assuming MacOS is current enough as well.) |
|
I wish I could reply to each message individually, but alas, I have to reply with some context quotes (see also @ferdnyc 's comment of "Github is confusing"). 😄 @ferdnyc :
This should already be a separate pull request under these two PRs: Regarding resvg, yes, it is very new, but I tested out several different methods of rendering SVG files and resvg provided the most features in a relatively small library (do one thing and do it well) that interfaced well with the existing code. I have updated the build scripts on my dev system to include the resvg library in the AppImage, so it would not be necessary for the individual distro to have resvg available. This would mean that distro-specific builds would lack the full rendering, so perhaps this functionality should be a runtime configuration item (detect the presence of the library and use it, if present, or set the path for it like blender and inkscape in the preferences).
Oops! You're right! I need to clean up those files!
Good catch! I definitely need to fix that!
I will look into this, too!
Yup, obviously debugging code that I had in place that also needs to be cleaned up or removed . It's this kind of thing that is hard to see in your own code and why I didn't submit a PR without getting feedback from you guys 😁
Thanks for the link to the list! I had not seen this before, either, and may help me find items to work on next!
If you're running a Linux machine, I can upload an AppImage for you (or anyone) to test. @peanutbutterandcrackers and @ferdnyc I don't have the dev env to build for Mac OS or Windows, but resvg is cross-platform (one of my requirements for the external SVG renderer).
Bombard away! Most of OpenShot is outside of my wheelhouse, but I use it all the time and any improvements that I can help with help me and, presumably, everyone else who uses it. I'll take the feedback and update my PR as time permits (not sure what this week looks like yet, so it may or may not be today or tomorrow). |
Yeah... and some of that confusion stems from the odd things they've left out. F'rinstance, I really don't understand why, in the Issues web interface, even when you select some text and use the 'r' shortcut to start a quoted reply, it doesn't attribute the quoted text at all. I won't even bother wishing for real threading, but who figured bare, unattributed blockquotes would be very useful? It's a very strange, seemingly social-media-influenced conversation structure. (With maybe the odd random feature plucked from email / more traditional online discussion, like the fact that you can quote previous "comments" at all.) Which I suppose may be liked for its familiarity, if it's the only style of online interaction you've ever known, but it's just not as good a fit for bug-tracking and discussion as they seem to imagine. Or maybe I'm just an old fart. Well, no, not maybe.
*nod* Though, having tried out the external-repo feedback thing for the first time, now, it's... not ideal. It should be simpler, but Github makes certain things a pain when trying to refer/interact across users' forks. Their concept of request-for-feedback code seems to want it presented as a PR. That gets it in front of the group (directly), enables the full power of Github's review flows (without the "oh, I can't comment here, but I can comment there..." struggle when going against The Github Way™), and... well, hell, it's even nice just to be able to refer to the proposed code by writing " #1384 ", instead of having to puzzle out cross-repo refs/links. 😁 You can always mark the PR "WIP:" to show that the code isn't ready or intended to be merged, like I did with #1384 until I was confident it was ready to go. (There's even a Github WIP app someone wrote that formalizes the process: It runs a bot that watches for PRs with "WIP" or "do not merge" in the text and sets them to pending status. Mostly that means it disables the Big Green Merge Button, looks like. So, in theory @jonoomph could install that in the repo to manage evolving PRs until they're ready for primetime.) In the end, tho, I think just getting the code out there, however it's done, is more important than the bureaucracy of how. So thanks for doing that, and looking forward to the next updates on this one! |
|
Yeah, I agree with everything you've said, so I must be just as old of a fart as you! 😆 So, for the sake of the flow that we're looking at with OpenShot, would you prefer I make a "WIP" PR for us to continue the discussion? |
|
I think it might be more convenient for us all to be able to discuss the changes that way, and it'd help corral the discussion into a single location, yeah. See @DylanC 's #1506 for an example of the back-and-forth we've been doing on that PR over the past few days. It sounds like this is getting pretty close, so I don't know that there'll need to be that much more discussion, but when you've got something ready for us to kick around again... I'd say shoot it over as a PR, sure. But that's purely my opinion, speaking only for myself. I don't know if @jonoomph has any particular views on in-development PRs, but I 'd say his opinion should carry the most weight since he's really the intended audience for them all, ultimately. |
|
Ah, I see... I can edit the title of the PR after I submit it, so I can prepend "[WIP]" to the PR title and remove it when it is ready. I'm going to go ahead and submit a PR for this, noting it WIP, for us to continue. Since I'll reference this issue, the bread crumbs should lead us where we need to go. [If @jonoomph says, "No WIP PRs, please," we'll deal with that at that time 😉 ] Thanks @ferdnyc ! |
|
@N3WWN - Yes, please! An AppImage would be great! Also, I am glad that the checklist could be of some help. :) |
Ew, nobody needs to see that. I try not to even allow photographic evidence of my existence, I'm certainly not going to start putting myself on video. The world already has reality TV if it wants to watch bullshit people doing their bullshit, and the ones on TV are far more attractive than this whole mess here.
It's hard to say without a lot more information, but... a couple of guesses/theories. You say this is the second video you created with OpenShot 2.4.3, and the first one performed well. HOW exactly did you transition from working on the first video, to working on the second video? Did you start a whole new project file? Load a saved one? Delete the clips from the first video off the Timeline and start placing clips for the second video? OpenShot currently has a large problem with session data buildup, both within an editing session and inside project files, where the session history is stored on save. Anything that involved continuing an older session, rather than starting fresh (ideally by completely quitting OpenShot, then reopening it and starting to build a new project from the initial empty state) might have caused your session to accumulate history data that's got it bogged down. One good clue would be the size of your project file for the current project when you save it. If it's huge (we've had reports in the tens of megabytes, for a file that should be a few hundred KB at most), then that's a good sign you're going to have problems. |
|
Ok, yes, then that's the explanation of what happened. For the next video will make sure that it's a fresh session and see what happens. |
Please do let us know. (Devs: If #2400 merges, we'll at least be able to advise users encountering these performance issues that all they have to do in order to return OpenShot to normal operation is save their work, restart the program, and load the saved project file back in.) |
|
Ok, here's review 2. First, I removed all but the title PNG from the existing project, saved it, restarted OpenShot and let it work. Found that it again was 37% and 1:30:xx remaining, down to 2 FPS. Cancelled it and started completely from scratch. So, new project, imported the title PNG, then added the ogg's and mov's for the video. Watched it initially go nice with 0:30 time remaining, but this soon went up. After I let this go for quite a while, I again started the old laptop with OpenShot 1 and started editing. This one was finished when OpenShot 2 at the 8 core showed 41.3%, 1:43:22 remaining at 3:40 FPS. I cancelled it. |
|
That's helpful, thanks. (Though, not very helpful to you, unfortunately.) Is there any way you'd be able to provide the project file and media for that project to us? (I don't know how sensitive the content is, obviously if it's something you can't share, that's totally understandable.) I'd just like to get an idea of the complexity and structure, and see whether I see the same issues. (I assume the answer is yes.) If you can't share the media, just the project file itself would be helpful, as it contains all the information we'd need about the media files in use, structurally. |
|
@ferdnyc What I noticed, is that (different from OpenShot 1), the .osp file is automatically changed and saved during editing. So even without actively saving changes and with cancellation of the editing process, the .osp file keeps all data added for the video. Can this be changed in preferences? |
Somewhat, yes. In the Preferences tab "Autosave", you can turn off... well... autosave, and that'll keep OpenShot from writing to the file on its own. However, at this time it'll still store your session history in the file when you manually save — PR #2400 proposes to eliminate history from the project files for the time being, but isn't yet merged into the code. The other thing you can do is lower the History Limit (in that same Preferences tab) from the default value of 20, which will cause it to save less history in the project file — but you'll also have less of a history buffer during your session, too. (Realistically, though, it's almost never useful to undo more than 5 or 6 steps. But if you ever use the "Slice: Keep Both Sides" feature to split clips, it's currently a quirk of how it interacts with the history that each use creates three history steps. So, it's worth taking that into account as well.)
Yeah, it's not, that's a GitHub thing. |
One thing I did notice with this is that, while all of the audio files are 48kHz, the project sample rate was set to 44.1kHz. So, the audio would all end up being resampled on export, which can definitely be a source of slowness (especially with vorbis audio, as it's not the fastest codec to process). Here's a copy of the project file with the history removed (though it was very small, really), and the sample rate changed to |
|
I'm not quite sure what's changed in this .osp file, but I'm getting loads of messages about each of the png files: "is not a valid video, audio or image file". 5 of them are blank, i.e. showing no content. And each time when I try to do something (e.g. remove) with any of them, the message returns for each. In the end, after finally removing everything from the timeline and project list, I try to load and insert them again with some of the files giving the same series of messages again, ending with those files not being loaded into OS at all. |
Agreed. The SVG specification is a large moving target which OpenShot will never be able to keep up with, so rendering is best left to a dedicated program, and ideally it would be the program you used to create the SVG in the first place. @peanutbutterandcrackers said:
The solution to this is to allow SVGs to be imported, but then for OpenShot to call Inkscape for you (if it is installed) to generate a PNG for display. New PNGs would be generated (and possibly cached) each time the user resizes an imported SVG or changes the video export resolution. |
It's a possibility. Inkscape does take command-line arguments to batch process files, and
That's not really the issue — the SVG support in Qt is actually based on a very well-defined and static spec. The problem is that the spec in question is SVG Tiny, because it's lightweight and QtSVG was mostly meant for icon rendering, including on mobile devices. Inkscape has no support for constraining itself to the features of SVG Tiny — so it's impossible to reliably write out SVG files from Inkscape that will be guaranteed compatible with QtSVG, even if you wanted to. Anyway, that's my final summary on this issue, best of luck with it. |
|
Qt uses SVG Tiny because the main SVG specification is a large moving target that they have no intention of keeping up with. Inkscape is heavy because they are trying to keep up with the specification (and because it uses GTK+). Performance shouldn't be a problem providing it is implemented correctly. Ideally PNG generation would be done in the background and on a different thread to OpenShot, with some kind of placeholder box displayed until the PNG was ready (or QtSVG used to render a placeholder / a previous cached version displayed). Each SVG to PNG conversion will take around 1 second, which is nothing compared to importing a video, but would start to add up if the user imports hundreds of SVGs. |
|
Everyone, OpenShot now builds (optionally) with resvg. Currently, all the installers (and AppImages) from the website have resvg as the renderer. The PPAs however, do not. If anyone wants to build libopenshot with resvg support, here is a script to install resvg and here is how one would compile libopenshot. Hope that helps. All we need now is for the distros to start packaging resvg. Closing for now. Thank you all for your help and insights into this issue. You guys are all awesome! |
|
The only improvement for me is that with the daily build of 2019-01-20 the svg handling is solved. What is NOT solved is the processing of the video from scratch: after 30 minutes, it showed a progress of 22.2% and 2:39:07 remaining time. I cancelled it, again. |
|
huubvanniekerk - Could you please attach the logs here so that we can see what is causing the slowness? Your system specs too, and any other relevant information would be of great assistance. |
|
openshot-qt.log |
|
Since the latest nightly-build, I can use OS quite nicely. It finishes in reasonable time without issues. |
|
@huubvanniekerk That's great to hear! The 2.4.4 release should be making it to rpmfusion some time very soon, as well, if you're interested in installing it that way. If you've updated to Fedora 29, there's a build going into -testing that I expect will be available in rpmfusion-free-updates by the end of the week. If you're still using Fedora 28, we hit a snag with the build servers so 2.4.4 will be delayed a few more days there. |
|
@ferdnyc After upgrading to Fedora 29 the other day, I installed 2.4.4 via rpm. Unfortunately, the first attempt in using it became a disappointment: it doesn't handle the SVG files properly. Since the 2.4.4 app from the website works fine, I keep using that version. |
|
@huubvanniekerk Yeah, unfortunately the ReSVG support in the AppImage isn't included in the RPM Fusion build. I'd like it to be, but there are a large number of Rust language prerequisites that aren't yet satisfied in Fedora. (Though I should check how much that situation has changed in F30 / new-Rawhide.) You aren't seeing the same color issues reported in #2697, with the AppImage? |
|
@ferdnyc I'm not using the title editor, so I can't confirm any colour issue with the AppImage. |
|
@huubvanniekerk That shouldn't matter, I don't believe it's related to the title editor. Could you add this SVG file (removing the |
|
@ferdnyc After importing it into the AppImage of 2.4.4, the big R renders blue, the rest of the text renders, orange/red. Same result after exporting it to a 1 second Youtube video. |
|
@huubvanniekerk Interesting! As you can see, for me running the 2.4.4 release AppImage, everything is orange, including the large R. I wonder why that would be different?
...But, real point is, all of that orange text is supposed to be blue. There's definitely some sort of issue with color inversion in the AppImage's SVG support. Not sure yet whether it's on the ReSVG side or in the libopenshot QtImageReader code. (Hm. I should probably try the 2.4.4 Windows release build, as I believe that also includes ReSVG.) |
|
@ferdnyc Now that you mention this... I do have a colour inversion with SVG, and that also occurred when I was still using version 1. I use svg files that have white text on white. After importing, they are white text on black. So, when I create them, I have a white sheet and have to make the letters white as well to have them appear as white text on black. I will try to create black text on white, since that reads easier, but will have to see how that works out. Btw, I use Inkscape to create my SVG files. |
|
@huubvanniekerk That may be a function of how you're creating the files. By default, Inkscape doesn't include the "page" background of a file in the SVG output, since SVG files natively support transparency. So, if you're creating white letters over a blank page in Inkscape, what you're really creating is white text on a transparent background. Because OpenShot is a video editor, its default background is a black field rather than a white page, so the letters will show up white-on-black. (Though, if you were to place them in front of another image or video, you'd be able to see that content behind the white lettering.) If you wanted to create actual white text on a white background (or any color background) in Inkscape, you need to also create a filled rectangle containing the background, then place the text in front of that. For reasons I've never fully understood, the option to show a standard "checkered background" transparency hint is a document property rather than a preference, in Inkscape. But to get a clearer picture of how the output will render, you can turn it on for an individual Inkscape project by checking the "Checkerboard background" option under "Background" on the "Page" tab of the File > Document Properties... window. |
I've seen this since one of the Openshot 2.3 versions (never used anything older than 2.3) and can confirm the issue is still present in 2.4.1 cuz I just used 2.4.1 to prepare the support files for this issue.
This has always been on Fedora 25.
I use titles to overlay statistics on my videos. I like to have fun with them (sometimes) and wanted a creepy font with fun colors for a Halloween-themed video I was working on.
Starting with one of the stock titles and using the Advanced Editor (inkscape), I created a title using the Shlop font, made it green and turned the stroke red.
This file is provided in the attached zip archive: Stage 1 stats.svg
Directly using/importing this SVG file within Openshot results in very different rendering, most of which is off screen due to the text anchor point being honored, but the alignment is ignored.
In order to better see how Openshot is rendering the SVG file, I copied the file and manually edited it, adding an x-offset of -800 pixels.
This file is provided in the attached zip archive: Stage 1 stats_offset.svg
In order to use this SVG file, I had to convert it to a PNG on the command line and import the transparent image.
This file is provided in the attached zip archive: Stage 1 stats.png
The OSP file is included in the attached zip archive, too: SVG rendering issue - 171128.osp
An Openshot 2.4.1 rendered video that shows each of the 3 files and demonstrates that the issue is present in the final export (not just the preview) is available here: https://youtu.be/1R6uUPfotss
SVG rendering issue - 171128.zip
Please let me know if I can provide any additional information or help.
Thanks!
-Rich
The text was updated successfully, but these errors were encountered: