Show HN: I created an After Effects alternative (pikimov.com)
Many years ago, I made VJ softwares (to mix live visuals in clubs) for unexpected platforms like the Game Boy Advance, the Playstation 2 and the Raspberry Pi. This year, I’m back with a new web-app: Pikimov.
Inspired by Photopea (a free Photoshop clone), I created this web-based motion design & video editor as an alternative to After Effects, to fill empty void.
It's free, without signup, without cloud uploads (your files stay on your machine), and your projects are not used for AI models training.
284 comments
[ 4.3 ms ] story [ 348 ms ] threadhttps://natrongithub.github.io/
"Open Source Compositing Software For VFX and Motion Graphics."
People don't like having bad or unhelpful AI features crammed into products but seeing the growth of ChatGPT, Midjourney, Adobe Generative Fill, Udio and Luma people definitely do like AI that actually works.
They're the same types who'll insist that DALL-E is just making collages of other artists' work, for example.
Personally I dislike being morally steamrollered on complex, nuanced topics.
People looked at this and immediately assumed this was added to allow Adobe to train models with people's private work.
Adobe has now updated their TOS, but this was a breach of trust.
Either way, in the end, this potential AI threat is just another reason to not store stuff in the "cloud".
Funny. In my experience AFK it is the people who use AI that have zero idea what it is and think answers can be blindly trusted. The ones who don’t like it can enumerate the drawbacks clearly.
FWIW I'm on the pro-artist side and anti-the current state of things, and wish we could start over with a collaboration between technologists and artists rather than each side having nothing but sneering contempt for the other.
"No crypto" labels in the last cycle made sense to me. Similar to "no ads", it points to the business model incentives and how the product is intended to evolve over time.
Conversely, "no ai" feels like a very fuzzy line around which editing features will be included (smart lasso tool? object tracking to frame shots? background / foreground selection?).
Though companies who want to see your data might not be so keen.
On my phone, but will try it out when I get home.
A bit fiddly for sure - but seems comprehensive enough.
That's an interesting question, but I think it's also equally difficult to prove for non-browser software.
With web applications doing the same is more difficult, because you need to pass some requests, and some requests need to pass while others could be smuggling data.
https://addons.mozilla.org/en-US/firefox/addon/work-offline-...
It does.
> You can, in fact, use the network tab to monitor a page's ongoing network activity as originally suggested.
Did you forget that this comment chain was about leaking data to the server? Observing that you have leaked (note: past tense!) your data is not a recommended way to prevent leaking data.
I am sitting here looking at a new entry added from a button click that creates a network call. Either you are wrong or confused about what the discussion is about.
Reading a historic log that shows you have been pwned does not prevent you from being pwned. It's the wrong tool for the job.
If you had done this, even spending 10 hours looking at network traffic, you wouldn't have been protected from this hack: https://www.theverge.com/2018/4/24/17275982/myetherwallet-ha...
That was a technically sophisticated hack, but there are simpler ones, like social engineering someone to take over their site.
Put putting hacks aside...
Say you have a site and it doesn't mention whether the data is sent to a server and you want to find out. Now let's say that site does a backup to server but only when localstorage has run out of space, but you don't know that.
When you test the site in the network tab, and you haven't run out of localstorage space then you will see no XHR and assume it's all good, it never sends to the server.
You then use the app for a few days, hit the localstorage limit and it sends stuff to the server without you knowing. And yeah you can keep the network tab open all the time if you have the discipline, but you only know once your data has been sent. It is too late.
If you care enough about whether it sends stuff to the server to look at a network tab, then you probably care enough to want to know for sure.
With the web as it is now there is only one way - trust the site and hope they do the right thing, and are secure. Or only put stuff on there you are happy to leak.
So, made up situation: if you are using this tool to edit and release a whistleblowing related video as a journalist. Maybe you shouldn't!
You probably instead want a local app, running on linux, on a machine that is disconnected from the network.
Future behaviour may be different.
Also on the web code can change. Either the site owner or by a hacker. There is value in checking network requests if you need to but it isn't fool proof.
- I pledge to only make network connections to X, Y and Z
- I pledge to only make GET requests to http://example.com/foo/*
- I pledge not to use canvas, iFrames or storage APIs
This info wouldn't be immediately useful to most users, but it could massively help experienced users with trusting local utilities.
Doesn't solve any trust issue since data can be send as part of the URL, and the backend response can change at will.
* first requirement can already be done using Content-Security-Policy header
* haven't found a suitable header for the second requirement
* third requirement can be done with Permissions-Policy header
Not relying on a server makes this functionality available for downloaded sites. I'm a big fan of offering single file builds for web utilities, and the pledge should be part of that build instead of something the user supplies.
Having this as a runtime API would enable easier integration - say I'm developing a video editor that needs some WASM blobs. It might be a lot easier to load the blobs and pledge no further network access than having the URLs known on the server-side.
15 years from now, will this site still be up?
Will you be able to open your projects from today, then?
I think web only is a really compelling way to get someone to try a product, but I’d much rather install a tool like this. Unless you could host the site yourself, of course.
- if the tool is updated continuously for 15 years it’ll still be up
- if it’s not updated, it will be technically irrelevant anyway and you’ll have switched to another tool by then
Future support is overrated for tools, just use one now and worry about tomorrow later.
Other points that weren't raised - I want to be free to work in situations where I have poor or no internet e.g. when traveling.
Tying tools down to whether or not a website is available and you have reliable internet access is a huge step backwards in my opinion.
I also use older software quite often that has long since been updated, such as older versions of Audacity, Ableton, Adobe Premiere, etc. for various reasons such as: not wanting to spend money, avoiding spyware, ads (see: Windows 11), and other bloat which often IMO negatively outweighs the positivity of new features. There are a lot of other small utilities that I still use that are 10+ years old because they still work fine and I know how to use them blind-folded. There are also tools that haven't received updates in many years but still work great, why would I bother to look for something new that potentially will spy on me and not offer the same functionality?
But sometimes you have important old projects.
For example, my parents used photoshop elements to touch up all of my sister’s baby photos.
But my parents were not very technical and kept most of the photos as photoshop project files.
Idk if project files that old will open in newer versions of photoshop, but I don’t need to worry, bc I can always find a download of that old photoshop elements and open the projects in there.
It’s not as much about daily use as it is about planned (or inevitable) obsolescence.
Everything web based WILL become unusable or change drastically some day.
One day, potentially out of nowhere, web based tools can just vanish.
Imagine you were working on a film school senior project and poof your video editing tool was just gone!
Even if they gave a week’s notice, that wouldn’t be enough.
That can’t happen with something like Sony Vegas.
I believe blender can do this, for example.
Nothing web specific about it.
Except I have to have those servers to run it on. It's the basic premise of why cloud vs onPrem. I didn't think that really needed to be stipulated at this level on this particular forum.
That software then does not require servers to run on, since it supports local processing.
In this way it remains accessible in the future and scalable right now. (Assuming local processing would be slow enough to hurt the experience)
Honestly, I didn’t think this concept needed to be explained at this level either.
Break the cycle.
That's an important distinction to make especially for a browser based app. It's also a very low bar IMO, but one that many other companies aren't clearing anymore, like MS, Adobe, and others.
There's plenty of alternatives to google analytics though. This sort of basic breakdown could be done with goaccess (or an awk one-liner); plausible, matomo or simple analytics would be decent options that cover most reasonable requirements.
I have a suggestion which has always served me well: Ask. Or don’t even ask, users will tell you what they want anyway. Analytics will only give you skewed information, as you are unable to distinguish the popularity of a feature is due to its usefulness, its prominence, or a general lack of clarity.
Non visible parts of aproject tend to get neglected a lot more if you just ask your users What will get more people talking to you, a 10% speed up split among many small interactions, or a visual glitch that doesn't affect usability but it's front and center?
And analytics won’t tell you that, so I don’t see your point.
> Non visible parts of aproject tend to get neglected a lot more if you just ask your users
Do they? Perhaps if you keep relying on analytics, they do. In my experience, users will just tell you anyway. And some of them will be better at feedback than others. Treasure those.
Also, and this is another topic, why don’t you use periods in your sentences? Your comment was unnecessarily hard to parse.
A good example is time tracking, people are notoriously bad at this, ignoring non events that consume time and over assigning time to task that demand attention
On the other topic, no real reason. I just suck at prose; I'll take the comment in consideration to improve that. That comment in general is just poorly written all around, I'd love to edit it, but the time window has passed
It would be great if you could use a self-hosted analytics platform instead! :)
And I would strongly advise not to develop based on anonymous analytics, users might tell you different desires if you ask them and use completely different workflows if added. Optimizing for web analytis metrics has ruined many projects.
I.e. 1. Newer API such as directory access, which would let the app utilize something like swap as necessarily. And only ever loading the data it can currently handle from the filesystem (https://developer.mozilla.org/en-US/docs/Web/API/File_System...)
2. Input doesn't necessarily have to be RAW/8k. You get several h of 1080p AV1 video within 4gb.
I think it ultimately depends on how much effort the Devs wants to invest to support large video inputs. If none is invested, then your assumption would be true.
I was unable to find the source code, so I wasn't able to check for myself. We'll have to wait for the author to chime in, if they're willing.
2. I'm assuming video editing software works on a raw format in memory with access to individual frames? Just like Photoshop would need access to individual pixels from an importend JPEG, the actual canvas uses a lot more memory than the compressed input format.
https://issues.chromium.org/issues/40691287
For speed, an editing app may also produce lower-res versions in memory for quick seeking and smooth playback, as a kind of quick preview. But that's easy to control how much memory you allocate for that, and even those previews can be stored or cached on disk.
Video editing is not especially memory-bound on modern machines. It's much more CPU/GPU-bound when it comes to applying effects, and IO-bound (including decoding-bound) when it comes to larger videos like 4K and 8K.
Isn't this no longer an issue thanks to SharedArrayBuffer?
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
I believe the ONNX Runtime uses this for multithreading on the web, see https://github.com/nagadomi/nunif/issues/34
I don't know if this project uses it, but there's ffmpeg.wasm [1].
1: https://github.com/ffmpegwasm/ffmpeg.wasm
Web Codecs can take a compressed media packet and get you the decoded image or audio buffer it corresponds to. Conversely it can take audio or images with timestamps and get you a series of encoded media packets you can then containerize (we say mux) and get you e.g. an mp4 file.
https://w3c.github.io/webcodecs/
https://www.theverge.com/2020/1/15/21067907/google-chrome-ap...
https://en.wikipedia.org/wiki/Google_Chrome_App
> Support for Chrome Apps in the Chrome Web Store was removed from Chrome in June 2022, except on ChromeOS where support has been extended until at least January 2025.
Are you planning on creating a company out of this? Are you going to monetize it?
1 - https://m.youtube.com/playlist?list=PL3pnEx5_eGm9BbCp2ZTj6LT...
> Why no Firefox support Firefox is my daily web browser. As a web developper, I always make sure my work is comptatible with all major browsers. But you can guess a web based video editor is a complex task to achieve, and Pikimov uses several key features that only exist in Chrome, Edge, and maybe Opera, and maybe, maybe, Brave. That's why Pikimov cannot currently work on Firefox (as of today: v127), there's nothing I can do to fix this, it is just not possible. For the curious ones, here are some of the web API Pikimov requires, but are missing from Firefox: - audio data - window showsavefilepicker - videoencoder Note: There is no Safari support due to similar obstacles.
https://pikimov.com/faq/
- https://github.com/mozilla/gecko-dev/blob/af09c55c0e6253ba8f...
- https://github.com/mozilla/gecko-dev/blob/af09c55c0e6253ba8f...
https://github.com/ennuicastr/libavjs-webcodecs-polyfill
I use Firefox for all my browsing, but do web app development with and for Chromium. I'd gladly do it for Firefox, but people, especially users, suck and sometimes one has to accept this.
Glad to see no time is wasted for Safari/iOS support. It's a huge waste of time and people using Apple devices are to blame.
It is the right of developers to say "I don't want to support your browser" and you should respect that decision even if you disagree with it.
As a reality check, see this ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=390936
It took Firefox 17 years of back and forth with developers to add parity with an Internet Explorer feature that Chrome supported since version 1. This late in the game IE is already dead for good.
Not everybody has infinite time or infinite money to support Firefox, as an aside, you knew what you signed up for when you made Firefox your main browser.
So please, change the "clarify why you don't support Firefox" tone with "I want to make the site work with Firefox, how can I help you?". And good luck making the Firefox team change their mind when they decide not to support X feature, because it is also their right to do not implement the whole spectrum of features that Chrome supports.
I think they genuinely were interested to learn more about the deficiencies of Firefox.
I did - a better browser than Internet Explorer. Granted, that was 20 years ago.
So I spoofed the user-agent in a nightly build here on my Linux desktop workstation, then had to alias one method that we should have implemented years ago but only have with a `moz` prefix (`HTMLMediaElement.mozCaptureStream`). This is on us to fix.
Then it looks like a worker script is served with the `Content-Type` `text/html` instead of `application/javascript` or something like that. We also have a pref flip to bypass that check, so I did that, but this is on the dev to fix.
When you do this it works, I've loaded project demos containing videos, audio, various things composited on top, scrubbed the timeline aggressively in a debug build, moved things around in various bits of the interface and also in the rendering frame, etc., things seem to work as they should, perf is as I'd expect it to be (and again, I'm running it in a debug build with optimizations disabled for anything media related, enabled for other parts of the browser).
What's missing is `window.showSaveFilePicker` and file system related stuff. It's possible to use https://developer.mozilla.org/en-US/docs/Web/API/File_System... instead (that we ship, e.g. Photoshop on the Web uses it). We think that it's much less scary than giving access to the file system to a content process of a Web browser. Maybe because videos can sometimes be extremely big files, direct access to the FS could be of use there. Thankfully, we also ship extremely modern video encoders to make them tiny instead, but that's currently a limitation Firefox has, for better or worse.
https://paul.cx/public/pikimov-firefox-nightly.webm
OPFS provides high-speed read and write for temporary files and non-exported files; again this is what Photoshop uses. There is a 10GB limit per domain currently. I'm not sure this particular app actually needs that, though
Obviously the permissioning model needs to be thought out here. It could perhaps only be available to "PWA"s that have been "installed", only on https sites, and only once explicit permission has been given, etc.
But it's so cumbersome to have upload/download be the only way to sync files into a web app.
Yeah other compositing tools exist but they lack the animation/mograph tools of AE, or animation tools exist but lack the scripting/filters/compositing.
But also, I would like to use motion graphics in an app where the software engineers don't have to re-implement each asset in code.
Comparing a web-based software that runs on your own computer vs. installing a (say native) software and frequently updating, isn't it interesting that the former is faster to do? When using a web-based software to ru on your own machine, you are effectively, momentarily, installing it and are able to uninstall by clearing the cache.
You can load+interpret JavaScript files dynamically as the user accesses certain features.
Targeting Chrome targets all of the platforms, and the machines and platform is "fast enough" to do the job without having to dig deep into specific nature of the platforms.
It also leverages, I'm assuming, the deep knowledge the developer has of doing other things for the browser platform.
They probably could have targeted some other portable GUI toolkit, but this was more familiar. It may well be an even smoother experience than using other cross platform GUI toolkits, plus, of course, the platform is free.
Finally, distribution is familiar and likely easier, it's truly cross platform (no need to build executable on the individual platforms, even if its all from the same source base), etc.
No bundling, no signing, no app stores. Just a URL shared in a tweet and you're on your way. If it was OSS, it could be parked on a Github page for all eternity.
Overall, it's a really attractive platform for developers, just not yet fully embraced I think, as client based applications I mean.
What are your plans for further development? I guess for this complex project to evolve in order to meet the needs of the professional users it will require lots of work/team/resources/etc.
Do you plan to monetize it somehow in the future? or how are you going to sustain it?
Another free alternative to AE (targeted at more casual users) that comes to mind is CapCut... which is obviously a ByteDance product. And they already offer tons of features for free, so the competition could be tough...
It will take significant resources, cash and teams to make this into a serious contender, and folks that have problems to solve will always be happy to pay decent dollars for great software.