PR merged, thanks!
@RexOr Note that the symbol you are using as 'beta' is most likely an sz ligature (or sharp s) and not a greek beta as the beta does not have a serif or swash at the bottom while the long s from sz has.
Good man. There's a new logo pack presently building.
Old (535 kb):
I am using this logo for the loading image on the vue.js version of the WebUI. So I fixed it (in my repo) but also forked the repo and created apertus_Logo_Pack_V2.2b.tar.gz with the fixed logo. I just made a pull request from our fork.
Just thought I would point out that the AXIOM logo in the logo pack as provided at github is cropped at the bottom:
Thu, Feb 22
NPM is just for the build with gulp or whatever. Device would get slim version of the page, pre-processed by NPM, less, uglified (if performance would be better) and minified.
i would suggest using vuex to store the "mutations" within the browser - but be careful with the latest NPM - they botched the release and it is chowning system critical folders - essentially bricking the device. It is only a temporary problem though.
Local storage data binding through vue.js would be great to have a central place. Seen that there is a npm package for that.
Yes, two way is built in and templating is why I suggested it in the first place.
Try it. JQuery is not a problem to remove, as it was used more for AJAX requests at the beginning. Does vue.js suppport two-way data binding? What about templating feature, by separating chunks into other html files?
Absolutely. I can look into this while building a git project if you like.
Shall I turn this into a git project with test runner, build instructions and switch out jquery for vue.js?
Did you get the image on IRC?
For the Controller/WebGUI/ControlGUI its currently me and @BAndiT1983 working on it. The current state is https://github.com/apertus-open-source-cinema/beta-software/tree/master/software/control_daemon/ControlGUI
Concepts are here: https://wiki.apertus.org/index.php/Wifi_Remote
Wed, Feb 21
So, I know that there is no Loomio decision making process here (our 150 person non-profit in Hamburg - the Gängeviertel - tried it too, with results similar to your experience...) but I still need some guidance from the core-team on how I should move forward and contribute. I can build everything I wrote about in the CONTROLLER, INTERFACE and DAEMON sections, but it is a considerable amount of work and will take some careful planning and integration...
Maybe something related:
Downloading fine here. Speed significantly slowed down in the middle, but finished fine, after accelerating again.
sorry I meant 403.
503 is not forbidden but service temporarily not available. maybe gitlab has a temproary outage (they sometimes do ;))
These two symbols are good for consumer trust in the project. Having beta-testers testing it around the world and confirming that it doesn't cause problems for them is also a chain of evidence that suggests due-diligence.
CE is mandatory for certain classes of equipment which we might or might not fall into, depending on the setup.
Those are GPL v2.0.
Question: I am trying to download this:
@sebastian sorry about the Terminology. (You did although just call it WebGUI and then link to ControlGUI...)
That also reflects what we have learned so far: Going to a lab and making measurements that show you are in compliance with CE is only for you to have proof in case you need in court.
When you say "Controller" do you mean the WebGUI ?
The amount of files on the fileserver is overwhelming, but the current versions are linked in the wiki, so i was able to commit them to Github.
I like some of the ideas over at snickerdoodle - especially their app-connectivity. Maybe there are some good ideas over there too...
Tue, Feb 20
Yeah, well of course this is something that the industry wants you to do. Considering the number of Betas out there, maybe just write up a simple declaration for each country where the product has been tested with a super official looking checklist, get it signed by the "tester" and someone from the organization.
The ball is on your side. Implement something which fits the requirements and we can test it on the Zynq, to see how it behaves.
I am seeing two different perspectives here, and just would like to have some clarification - or even better some benchmarking stats. For your information I have done work on arduino, raspberries, Olimex a20-SOM / LIME (including custom flashing of the NAND), Banana-pi and the O-Droid C-1 - so I am VERY aware of paying attention to system resources and the tough design decisions that come with that.
It went not well, while GSoC2017, without going too much into details. So i've resumed the work on the daemon, REST server and GUI. The goal is to get rid of scripts to get performance gains. Don't underestimate it, it's an embedded CPU, resources are sparse. There is a reason why C++ was used.
Ok - I've noted what you said @jatha - thanks for the info. Can you tell me where to find the spec for the openAPI and Plugin Modules?
If i remember correctly, then most of this things were discussed with Herbert for the daemon, which was a task for GSoC2017. If you can get it through bash script, fine, but i'm rather sceptical about the performance. Surprise me.
There are some things, that are good to consider, when we build something like this:
- The camera has plenty of resources. When designing something that only works on the parameters, and not on any image data it is almost impossible to design a system that is to imperformant to run on the cam. This means no performance optimisation is needed.
- The software has to work without requiring internet access at all. (in my opinion) I think it would be handy if everything is served from the camera.
- The software should manage the state of the hardware (is the fpga configured? what bitstream should be loaded? what bitstream is loaded? what plugin modules are plugged in?
- New Plugin Modules should be easy to integrate (new bitstrams and new parameter space)
- An open API should be exposed to allow other interfaces (maybe hardware) to be easily developed
please take a look
It is planned, but wasn't done yet, as we have lack of people, who are involved in practical way.
I thought I read somewhere that there is a virtual machine image that I should use to spin up development... Maybe I imagined that.
Which VM image?
Challenge accepted. Can you point me to a resource for a current VM image?
Daemon was started, amongst other things, to remove the need for that folder at some point in time. Feel free to implement something, which could replace current approach.
Then maybe a single long running bash script with a high priority / nice-value running as a main control interface that listens for changes to the fifo and where necessary modifies the fifo / and non-volatile file-store for use on startup for init and conf...
The goal is to avoid to use bash which spawns a lot of threads and to have a central point which should do the configuration and initializations.
Basic infos about it are here: https://wiki.apertus.org/index.php/Control_Deamon
I think there is a misunderstanding. Node.js is used by me for current tests of PCB inspection, if this software will be used, then on a normal server. The camera has an embedded processor, so we won't use Node.js there. Won't ditch C++ also, because of performance, small footprint and rather simple daemon implementation.
Mon, Feb 19
Exactly. Going further, you could also allow users to opt-in their hardware into something like a "fleet health check" which would be a pathway to send errors / regressions / heat statistics whatever back to HQ for QA...
As far as the my.apertus.org idea is concerned, it might be worth looking into a scheme that serves unique / registered apertus hostnames on a subdomain with the cert being held on the device.
AND ... you can get rid of the custom C++ code cruft for simple api responses.
if you are already using node.js for socket.io it is perfect because it is a breeze to bind two-way into vue.js...
Yeah you are completely right! Axiom Firmware would be much better!
Moreover, I quite like the idea of having repos for each topic (like gateware, web-gui, daemon, configs, ...)
As the software grows, it maybe a good point in time to split in in sub-modules, so the things do not interfere. How would we split the things and keep track?
Fetch API or Axios was considered to replace AJAX stuff from JQuery. Some tests done, but not added to the main code.
All the PHP is still the axiom alpha and will be deprecated in favour of the new REST api. (correct me if Im wrong).
Some of your suggestions are already taken care of in the next-gen firmware on github (ie. lighttpd not having sudo rights)
I have to agree with davidak - and go one further:
Sounds cool :).
I think we dont need to optimize for speed so caching is not really important (for now).
The performance for our webapp is excellent - even on mobile. We are using lots of components, routes, icon-fonts, 8 translations and roboto font though. I think for apertus it could be really slim. According to the design mock up you need:
What is your experience with the performance? What about application size?
We are using in a framework for vue.js called quasar. With one code base we deliver a single-page website, electron native apps for windows, mac and linux and also use cordova for making android and iOS apps. It may be a bit of overkill for your use-case, but if you plan to deliver for more than just phones, maybe it makes sense to tool up at the beginning. That was our decision - and I can say we do not regret investing some extra time early.
Ah, you want to use it like the R&D at my company. They have also implemented an Android application in that way. But a simple WebView app for Android would be sufficient, in my opinion, maybe with settigns for IP address of the camera. Done that already at work, as we had no requirement for Cordova for customer project.
Current state of testing PCB inspection:
cordova would be a build step to make native apps that run within a "webview" container on a mobile device.
Heard of vue.js before, but haven't used it. What PHP thread do you mean? Currently we do not involve PHP at all for that part of the software. There is a C++ daemon and REST server (also a Go version exists, but not maintained currently) which are used to communicate forth and back.
One other thing about the designs you linked to, a website in a browser will pretty much always have the OS chrome and Browser chrome at the top. In landscape mode there is a lot of real-estate that goes away. There's probably a way to do that with html5 fullscreen - but that is a part of the spec that browsers / os's have never really gotten right. It will need some testing and tweaking.
And if this seems like a lot to digest, next week I can set aside an afternoon to help you create the tooling and tune the build process in a separate git repo - then you just need to park the submodule in your main repo and you'll be good to go.
Ok. I would highly recommend taking a look at vue.js - its templating features are exactly what is needed here - it has your "ajax" and data-bindings. It is also very lightweight.
The general idea is to use a smartphone (but later also tablet or laptop) to control the camera. Sebastian did some mock-ups of the UI before (current implementation is a bit different) -> https://wiki.apertus.org/index.php/Wifi_Remote
Before I can really answer that, I would need a really quick 3 sentence explanation of EXACTLY when the users see this interface and on what screens - or even better, a link to the spec page.
At the beginning we wanted to do something with plain JS, but as it is more comfortable for user to have single-page app, the need for more advanced things arose.
In my opinion, until the networking stack and sudoers permissions are hardened in the Beta Software package, any exposure to the lighttpd service is really dangerous...
I can definitely recommend some sort of build pipeline tailored to the final delivery platform(s). Gulp is a great start, but there are also other options. Having a node based build system is very comfortable - but setting it up can be a great deal of work.
i think aes256 would be much more practical to use. with otps one would need to store twice the data, which is not very easy. When crossing borders with footage, one would most likely carry both storage mediums (the footage and the key), which would make the encryption useless. when using aes, we could encrypt the key with a password and therefore keep the footage secure, even if all the storage mediums are confiscated.
For reference, here is one approach: https://sites.google.com/site/nxcryptophotography/home
Sun, Feb 18
It wouldn't harm exploring A5 when it comes to print one day no doubt. That would be quite a handy tool for fairs etc... but It would be worth having a later version for any printing. eg. the three Options and Pricing pages need better images. We may be able to get something solid for a page on AXIOM Recorder possibly too. There may be general improvements to be made as well. For the time being it's presentation serves a good immediate purpose when it comes to email communications which is what I needed the doc for, however, you have real skills, I've just done what was necessary.
@RexOr what will be the final document size? DIN A4 Landscape or DIN A5 Landscape?
Thu, Feb 15
new potent candidate: http://com.odroid.com/sigong/blog/blog_list.php?bid=193