I’m sorry, I think this conversation has become one sided and I can’t seem to establish a constructive dialogue with you. Perhaps I wasn’t able to make my point clear enough and I am having serious trouble understanding yours. This idea of a feature being discarded a-priori without even having tried a demo evades me, but perhaps I’m just not used to how things work “round here”.
On the other hand I got more or less what I wanted with my own method without needing to convince anyone, so I thank you for the discussion, but I see no point in continuing further.
You don’t need to test a car with no tyre on one wheel and no seatbelts to know the shape of things to come for anyone who still thinks its drivable.
That’s not a “round here” thing. And not enthusiastically wanting to take it for a spin isn’t “being negative”.
But you are right that I find absolutely mind-boggling the idea that you not only designed it that way from the outset, but that you actually seem convinced and very determined to convince others that it’s ‘quite elegant’.
I don’t think you actually are deliberately trolling for horrified responses, though if you were it would be 4 stars for apparent sincerity, so maybe it’s just a sunk-cost / face that only a mother could love thing.
Good luck learning from it, but if you can only understand one thing I’ve said about this until you do, please make it “don’t inflict this on other people until you find a much saner way to do it and/or understand why I’m saying that”. We make stable machine interfaces for a reason, and playing telephone with svg’s isn’t one of them.
aaight you know what, let’s start over, please forget all of our discussion and riddle me this:
I have imported an 1080x1920px SVG file in a project with some shapes that I use as overlay for my footage. I would like to edit the shapes in a way that matches the position of various elements of the underlying video, however I find it hard to do without having the video itself as a reference so I can draw “on top of it”. I like the way it works with glaxnimate as you can just double click the clip in the timeline and glaxnimate opens up and automatically adds the underlying footage as background for reference. What are my options, right now, to replicate a similar workflow (at least the part where I get a reference background) for SVG graphics and with vector graphics editor of choice?
This was something that I thought was self-evident from the earliest posts, once we got past “you’ll get the best results using images that match the project frame size” - but perhaps not, and perhaps I wasn’t actually explicit enough before you slid down the slope of over-engineering your way past the very easy answer.
At least if we take your originally stated requirement at face value:
Then the simplest answer (which I thought was obvious and use a lot myself), is to create a library of the kind of shapes you want, with the proportions you want, filling all or most of the document space (because scaling down tends to be easier than scaling up), in a neutral colour (I often use white) except for any graded embellishement you might want, like a drop shadow with alpha, or contrasting outline etc.
Then when you want a shape somewhere, you start with the generic, unpositioned, library image you want to use, and for each timeline copy where you want it to highlight something, you add a transform effect to scale and position it where you want it. If what you’re highlighting is moving, then you can use the motion tracker to keyframe that and have it follow your subject perfectly.
If you want it a different colour, or want to fade it in or out or grow or shrink or flash or whatever, you do all that with effects in kdenlive, and you never need to open inkscape ever again after creating all the base library shapes that you want just once.
Doesn’t need any trickery or hackery, or any switching back and forth between apps to get it right, you just use all the tools they way they work best, and it’s all easier and more robust than what you get trying to Be Cleverer than what the tools were designed to do.
Doesn’t even really matter which app would get opened if you try to edit the image from kdenlive, because the shapes in a good library should generally be immutable, and if you need something different, you instead create a new generic thing to add to the library.
What are my options, right now, to replicate a similar workflow … [to glaxnimage] … with vector graphics editor of choice?
What we’ve also been trying to explain since the outset, is that the only sane way to “replicate what glaxnimate does” is to do it the way glaxnimate does, with an actual stable machine interface supported by both tools.
If there was some easier or generic way to do that reliably, it’s what we would already be using for it too.
The only promise you get from round tripping an SVG through some other editing tool is that it should (but may not due to implementation differences and incomplete support for all of the standard!) get rendered with only the changes you made being visibly different. But nothing requires the original internals to remain recognisable by the tool that first created them (or previously changed them) at all, so long as they would render the same visible image under the applicable standards.
It is perfectly possible to drive home blind drunk and not stop at any red lights. And a quick first test might ‘prove’ that really works. But if you want to depend on it working every time you go out, it doesn’t take a crystal ball to see the future.
By the time you’ve implemented enough SVG support to do this with even a vague hope of reliability in the general case, you might as well just get rid of inkscape and all other other external tools and be the editor yourself.
So it’s good that none of this sort of Too Cleverness should really be needed at all for the case you originally set out.
What can’t you do, about as efficiently and easily as would ever be possible, with a simple shape library like I’ve described above, that doesn’t depend at all on the ‘background reference’ except at the point in the timeline where each copy of the same generic image is actually being used? There’s no need for back and forth between apps, you just make images once and use them as often as they are useful.
I have worked with a library of shapes quite some time. The issue I have there is the stroke width, as scaling an image outside of a vector graphics editor scales the stroke with it. Moreover, if the scaling is not x-y locked the stroke becomes deformed. This means that, for instance with ellipses and rectangles, scaling in kdenlive is not a desirable option, and the alternative would be to either have A LOT of those pre-made shapes to cover all use-cases, or to make new ones on the fly, which is of course an option but basically we come back to the “editing SVG files to match the current situation” which led to this whole discussion.
Now I will admit that for rectangles and ellipses glaxnimate is perfectly usable because there I don’t need massive precision, so even a “gridless” tool does the job and does it well because of the automatic background thing. Excellent.
In fact the title editor in kdenlive is perfectly fine for this purpose, super handy, if it weren’t for this bug which I reported quite some time ago (actually I’d like to fix it myself if you can point me to the right direction)
Arrows are another story as they have fill and stroke. When scaling an arrow (to an extent) I would like the stroke width to remain constant. This can be done in a vector graphics editor. However another common use-case is resizing an arrow’s tail (basically making it longer) without changing the proportions of the tip. This is where glaxnimate completely fails to deliver, here is why:
There is no grid, so I can’t draw a precise arrow to begin with
There is no pre-made arrow shape which one could then scale and adapt
one can import a “straight” arrow into glaxnimate from an SVG, however editing it precisely is simply impossible.
point-editing without a grid is just not possible. Another approach is to make the arrow as separate tip and tail shapes and then group them, then just scale the tail without rotating anything. However even there glaxnimate makes this impossible because (i) scaling a shape scales the stroke with it, with the aforementioned deformation and (ii) scaling is relative to the center of the shape, so once scaled the tail would have to be realigned with the tip, coming right back to it being impossible due to the lack of a grid.
This problem is what brought me into this discussion and prompted me to work out a solution that would allow me to draw arrows with a more competent vector graphics editor. The reason why having a reference background is useful is that arrows often need to point from one item to another, so it’s nice to be able to adjust the length of an arrow precisely without having to scale the arrow in kdenlive (or arrows of different length would have slightly different size). This is why I figured I could at least partially automate the process of grabbing a frame and setting it as background to the SVG file where I would draw the arrow, and then removing it.
This would all be solved if glaxnimate had a grid, but there is altready a 3y old feature request so I have little hope there. Until then one tries to be resourceful and find some workaround that is somehow acceptable, hence the famous python script.
So my question is: even though you might not personally relate to my perceived issue, can you try to step in my shoes see why I (or someone else) might perceive this as a problem, and why I tried to address it by going past the classic “library of shapes” method?
Which in most cases is the desired behaviour. If I render something that started in 1080p at 4k I want everything to be twice as wide to maintain its visual proportion, and vice versa. It’s why you use vector graphics and the defined behaviour when rendering SVGs.
if the scaling is not x-y locked the stroke becomes deformed
Which is sometimes what you want for aesthetic effect, and generally not visible until the distortion is large. But that’s why you have a library, so you can start from an object that needs minimal distortion.
And even then if you’re still not happy with the result, it’s completely trivial to open the (copy of a) library file in whatever editor pops up when you click edit, nudge its proportions, hit save, and have that change immediately appear in kdenlive as part of whatever complex and possibly otherwise transformed composition it appears in.
And if that still doesn’t make you happy, it’s only 2 keystrokes to export a frame which you can then use in any tool, in the truly special cases where Nothing Else Will Do.
the title editor in kdenlive is perfectly fine for this purpose, super handy, if it weren’t for this bug
Which I can’t reproduce in the current appimage, but let’s deal with that in the bug report.
Arrows are another story
And there is also a perfectly good library of unicode arrows, in a near infinite range of fonts, that you can use from the title tool in many (but yes, not all) cases too.
This would all be solved if glaxnimate had a grid, but there is altready a 3y old feature request so I have little hope there.
Have you talked to them and asked if they would accept a patch implementing it? We have plenty of old feature requests too, which are only still just requests because time is finite. They didn’t reject the idea and it’s tagged as a milestone goal for version 1.0.0. Chances are they’d welcome being handed it on a plate.
So if you have time to burn on hacking up something fragile and ugly, why not actually scratch your itch properly once and for all. You obviously have clear ideas of what you want and actually do this enough that they bug you. Your two real options here are push inkscape to do what glaxnimate can, or push the other way. And if you want the tight integration, adding snap points to glaxnimate seems like the much shorter path.
can you try to step in my shoes
I think you’re still straining if this is the story of why it’s worthwhile continuing to invest more effort in the experiment with using SVGs for IPC. It’s a cute “fencing wire and duct tape” hack, but it’s never going to sell in the kind of shops where All Good Editing Tools are sold.
You can get 90% of the way to where you want without it just by using the existing tools to their fullest abilities, and there is no easy way to cleanly get that last 10% for the harder corner cases without doing something like what glaxnimate has done. Or implementing a full featured vector editor in kdenlive (and a better title tool has been on our “wouldn’t it be nice” list for a very long time too).
I’ve never said there’s no room for improvement here. It’s the great outdoors for that. I’d just rather see all that energy directed toward creating an actually robust solution, built on best practice - than have it promoting a half-assed weekend hack which at best will be ignored by everyone else, and at worst will magnify the wasted time which could be spent on better things, when “I’ve been using this tool I found at … and the latest kdenlive/inkscape/distro/windows update has broken it, please help me” becomes a faq here - like it is for the people using packages from certain distros instead of the appimages.
I don’t want to hose down your enthusiasm. I’d just rather not see it working for the dark side.
Alright, I think I see more where you’re coming from now. I’ll try to get in touch with the glaxnimate developers to see about the grid but I don’t think I’m equipped to actually help them there (both in terms of time and skills).
In the meantime I corrected the bug report I mentioned before, indeed I missed a step to reproduce the issue, now you should be able to.
At the risk of going off topic one sec, there is another (small) issue regarding vector graphics that I would like to address, which is that any form of anti-aliasing seems to do alpha blending “wrong” as in, there is often a ring of darker pixels around the edges of a shape. You can see it in this video of mine at min. 2.26 in the red ellipse.
Should I open a bug report where the other one is? or should I mention it somewhere in this forum?
That I’m pretty sure is a colourspace/gamma correctness problem, probably in the underlying libraries we use, but it is annoying and does need investigating and correcting. It’s apparent in the vignetting and other alpha feathering operations too, and not at all specific to vector graphics (it’s a raster compositing problem).
[It’s a Well Known Problem, from the same class of “Well Known” I’ve been cringing from here An easy mistake that lots of people innocently make until they have enough of the right bruises to know better.]
So we might not be able to fix it in kdenlive, but this is as good a place as any for someone to start investigating it from - so if there isn’t one already, please do open a report in the bug tracker for this one too. Feel free to quote the above, including that reference and a screenshot from a suitable frame of your own video.
We don’t use this forum for tracking bugs, but it is the right place to triage “I’m not sure if this is a bug” and “I wonder if this idea I have would be feasible” questions.
That article is a very good read, I implement a fair bit of real-time image processing on FPGA and I never knew about this, but reading it it makes perfect sense and I will apply this knowledge to my work going forward (btw it has some nice parallels with the audio world).
However call me crazy but I think figure 12 makes the opposite point of what it is set out to. If I squint I think B is a much closer match than C for the original image, and it does make sense since as was stated earlier in the article, an RGB of (128, 128, 128) should be perceived as “half as bright”. But maybe there is some additional gamma distortion going on in my browser/screen
I stumbled onto this discussion by pure chance. Lots of toing and froing. But thanks @sideprojectslab for pointing me to Kdenlive to start experimenting with custom SVG objects .. in production workflow. How many realise an old party trick that SVG objects can be dynamically changed by embedded PHP? When I find time I will experiment with Kdenlive. I too have many “sideprojects” in play. Perhaps too many. But visualisation of constructs by SVG is key.
The fundamentals of signal processing are the same in both domains, and the best compression algorithms for both operate on them in the frequency domain.
Some of the lessons learned from Opus translated very well to Daala during the AV1 research.
I’d guessed it might have had something to do with that image getting rescaled again, somewhere between the original example and what ends actually up rendered in a brower - because you’re not crazy, it looks bogus at the scale my brower is showing it to me too.
As an example it kind of shows the problem well, even if not exactly in the way it had intended to …
For this color issue, the best workaround I found so far is to choose a different color for my shapes. The trick seems to be having a fair amount of intensity on at least two color components. I landed on warm yellow (hue: 50, saturation: 255) but most mild “pastel” colors work very well.
There might be some things that kdenlive is doing wrong which contributes to this, but most of that stuff is out of our control - we just pass the source material and desired manipulation configuration to MLT, which in turn passes it on to the effect plugins and libav (ffmpeg) et al.
I’d probably start by looking at MLT, and passing some simple examples that exhibit the problem through it, tracing though the code to see who is getting it wrong (but it’s probably going to be lots of places, all making the same naive blending mistakes).
Ok good tip, could you point me to an example of this happening (passing data to MLT) in the kdenlive codebase? To keep the scope small for now let’s say one has overlapping items in the timeline (a title and some footage for instance), where does the blending happen?
I’d probably start with picking a very simple example that clearly shows the problem (two images with alpha, or one with an alpha shape or vignette etc).
Then figure out how to use MLT’s low level tools to create the same example without kdenlive. Then go down the rabbit hole of twisty little passages to possibly end up in libav or whoever implements that effect or composition.
Then take what you learned from that to find the next example that still has the problem and lather rinse repeat.
It seems I can’t upload project files here, but here’s a really simple one to kick it off that’s just a colour clip and an alpha mask which shows the halo at the inner edge: debian Pastezone
The advantage of it is there’s no external resources or complications, just a flat colour frame MLT synthesised and an effect provided by frei0r (which should make it easy to create your own ‘fixed’ frei0r plugin for testing).
If you do decide to bite this mushroom, we should probably open an issue here where we can track it and share files in a slightly more civilised way, and then have something coherent to present to the upstream developers if/when it gets that far.
An easy mistake that lots of people innocently make until they have enough of the right bruises to know better.]