Software Roadmap - 0.3.1, 0.4.x, etc.
- Thread starter DDR
- Start date
hi DDR
thanks for your reply.
Now we have a camera with Arogo linux running on it. Do you mean now it's NOT able to run the GUI app @ https://github.com/krontech/chronos-gui-2 on our camera? But it's able to run at Debian 7 Vm on a computer?
Thx
thanks for your reply.
Now we have a camera with Arogo linux running on it. Do you mean now it's NOT able to run the GUI app @ https://github.com/krontech/chronos-gui-2 on our camera? But it's able to run at Debian 7 Vm on a computer?
Thx
DDR said:Hi Sam!
Instructions for compiling the UI on the camera are up at https://github.com/krontech/chronos-gui-2/blob/master/util/chronos%20debian%20setup%20instructions.txt. However, they assume you have a camera running Debian 7. Only our development cameras run Debian 7 at the moment, since we haven't done little things like got the camera image sensor working yet. (The 0.3.1 release is based on Arago Linux instead of Debian for this reason.) However, you can - and I am - running the new UI in a Debian 7 VM. I do have instructions for setting up the VM using VirtualBox, but they're really not very nice and I think you're much better off following the nicer camera instructions linked at the top.
------
As for the software, I have just finished the first real implementation of one of the screens. It's wired into the mock API for now, until we develop the real one. (I haven't implemented the real API yet, because there are several people here who could reasonably implement it, and I'm the only UI person we have, and I'm really hoping to fob it off on one of them.The drivers are *almost* ready for it though! We're so close!)
As an update to the previous progress chart:
While it may be removed, a tentative motion trigger screen has been planned. This is not an official acknowledgement that such a thing will ever be made, of course - the UI plan I have will probably grow a number of things which will never be, but which I should at least leave some space for in case they do get added. The act of UI design is overly optimistic in that sense.
The Record Settings shell has been wired into the API. This is a fairly complex page, so it's been a good testing ground for the wiring process. It appears to be a verbose and somewhat error-prone process, without particularly good control over the flow of data. However, it works, and optimistically it appears each page will take about 2-3 days to put together at this point. Perhaps the whole thing will be wired into the real API by the end of October. :-\
I also made the About & Kickstarter page reflect actual camera data, rather than just my placeholders. So that's good, and it counts as done as well although it's not particularly newsworthy.
I've attached the full roadmap picture below as well.
Hi, SamL. You are correct. The GUI app, chronos-gui-2, currently only runs on a computer. This will be fixed in version 0.4.x. (0.3.x is the latest currently released version.)
Currently, chronos-gui-2 does NOT have the ability to record video or play it back on our camera. It's a work in progress.
Currently, chronos-gui-2 does NOT have the ability to record video or play it back on our camera. It's a work in progress.
Oh, got Implementation (Front-End) → Power in today! Took me a day or two to figure out how to draw the graph, and I'm still not 100% happy with it. I'll fix it later, though. It's more important to get it working right - and in your hands - than it is to get the colours correct.
For several of the applications I would like to use my new Cronos 1.4 it would be really beneficial to have the ability to use the "Run-n-Gun" and the "Normal + Continuous" recording modes mentioned in the User Manual. I didn't see any express mention of them in the Software Roadmap and was curious as to when we might see that feature added to a software update?
RoboChair said:
Unfortunately we don't have a timeline for this right now. Those two modes require the use of dual video ports on the camera's CPU (one for live view, one for saving). We've come to find out that Texas Instruments built in no support for this in their software, even though the hardware has two fully functional video ports. Getting the second port running is a very large amount of effort, and is lower on the priority list compared to major, commonly requested features like Ethernet remote control, image quality improvements, and HDMI.
Very soon. It's been in pre-release testing for a few days and nothing catastrophic has happened yet. We'll be able to release it today, with luck!edmond said:
CinemaDNG Raw recording should be in today or tomorrow, with the new release.Dan Kanes said:
If I recall correctly, I think BlackMagic Raw is off the table for now. I think we can't record it without giving someone a rather large pile of cash.
ThomasYiPP
New member
I guess something catastrophic happened...DDR said:
It's great to see the progress on 4.x, thanks for keeping us in the loop with the nice roadmap
There were... issues.edmond said:
In fact, there still are issues, but those will be fixed soon. Foobar's fixed a DNG import issue? as of 7 minutes ago now, we think. (It's still got to be tested though. From what I've heard around the office, it should be possible to imperfectly fix the DNG files recorded with the current beta. We haven't tried, though, so take this with a grain of salt.)This sort of delay is why we try to avoid saying we'll do things. We're very wrong, very often, and it is never in the direction of "sooner".
On that note, I myself am trying to get the jog wheel to work with *absolutely everything*. If I can get this working as I'd like, we'll be able to do stuff like use the camera with mittens on during cold weather. I'm currently trying to figure out how to read from the FIFO file which reports jog wheel position, and then how to interpret that to a rotation, and how to get THAT into a reasonable event in the QT framework? and then I need to actually make the widgets behave correctly. It's a surprisingly long road, I've been at this particular task a few days now.
I miss the web. It would have been onscroll="whatever()" there. But of course, the web has other issues.
That's why an increasingly high number of devices just use HTML/CSS/JS for their UI and slap a basic webengine on there to display it. not as fast as natively coded ui's but allso much less hassle and the same tech on all platforms.DDR said:I miss the web. It would have been onscroll="whatever()" there. But of course, the web has other issues.
Bernard Rousset
New member
Hello,
You are very efficient and it is very nice to see how the software is getting better and better. I have bought one black and white (in fact grey) camera for scientific purpose. I do not want to make pretty photos and at the end I use a threshold to obtain only two colors black and white to define particules I will track though the frames. One. Anyway at first I need raw data and one Of the issues is the number of frames inside one record and also the time to save it. I will be very pleased to check the raw cinepack option.
I also wonder if a recording and saving in 8 bits (corresponding to low light) could be an option in the future ?
Have a nice day (or night depending on which side of the sea you are...)
Bernard
You are very efficient and it is very nice to see how the software is getting better and better. I have bought one black and white (in fact grey) camera for scientific purpose. I do not want to make pretty photos and at the end I use a threshold to obtain only two colors black and white to define particules I will track though the frames. One. Anyway at first I need raw data and one Of the issues is the number of frames inside one record and also the time to save it. I will be very pleased to check the raw cinepack option.
I also wonder if a recording and saving in 8 bits (corresponding to low light) could be an option in the future ?
Have a nice day (or night depending on which side of the sea you are...)
Bernard
It is hurting saving all the nonessential data, isn't it?Bernard Rousset said:
We do like the idea of saving at a reduced bit depth, but it would be a fairly far future thing if we did it. Unfortunately, there are several other things that need our attention first. Motion triggering, (most of the) text overlay, power control, etc.I was considering that, actually, but rejected it for performance reasons. Even the new native app I'm working on is having trouble rendering at a decent framerate right now. It's usable, but it's not ~buttery smooth~ like the old one is. Since most of it isn't my code, and I haven't done anything obviously wrong, it seems like it's some combination of the new libraries, the upgraded framework, and the easier-to-touch styling. :-\NiNeff said:
Hi SamL. I'm not sure when the HTTP API will be released. However, for you and everyone else curious, an explanation is is order.
Here is a map of the tasks we're working on. (Click for larger version, or see attachment 1.)
Green = done
Yellow = in progress
White = not started
The blue circles denote areas we're actively working on. In order:
❶ One of our engineers, Johan, is implementing the underlying D-Bus API right now. The HTTP API (not pictured) will act as a wrapper for the D-Bus API, so as the timing works out, when the D-Bus API is done the HTTP API should be done as well. Johan has so far implemented reading the power controller for battery charge, and is currently porting reading/writing to our FPGA. Soon, we can do actual useful stuff with the API, but how soon is unknown. Johan hasn't done this before, and therefore can't produce an accurate estimate. I'm guessing it will take him at least few months to work through everything. Assuming we can get out some sort of gimped HTTP API built on that work, which won't run simultaneously with the touch-screen user interface on the camera, I would very roughly estimate "late January" for basic HTTP control. This should not include video streaming, but should include video download and basic file management.
❷ I am continuing work on the new back-of-camera user interface. I've spent the last two weeks working on one of the two great unknowns of the process, jog wheel input. The other great unknown, the software keyboards, I will start work on tomorrow. I don't know how long the software keyboards will take. They could take a few days, or they could take a few weeks. The jog wheel still needs roughly a week or two of work, as each widget needs its own behaviour implemented. (Menus are going to become a heck of a lot easier to select.
)
❸ Foobar has effectively ported the current UI forward to our shiny new Debian-based operating system. This is a major milestone for us! It means we can abandon our old operating system, which was sucking up a lot of our time. It also means we can do a more piece-wise release of the new features as they're built out, so we may see useful parts of the HTTP API available well before the full HTTP API is finished.
Here is a map of the tasks we're working on. (Click for larger version, or see attachment 1.)
Green = done
Yellow = in progress
White = not started
The blue circles denote areas we're actively working on. In order:
❶ One of our engineers, Johan, is implementing the underlying D-Bus API right now. The HTTP API (not pictured) will act as a wrapper for the D-Bus API, so as the timing works out, when the D-Bus API is done the HTTP API should be done as well. Johan has so far implemented reading the power controller for battery charge, and is currently porting reading/writing to our FPGA. Soon, we can do actual useful stuff with the API, but how soon is unknown. Johan hasn't done this before, and therefore can't produce an accurate estimate. I'm guessing it will take him at least few months to work through everything. Assuming we can get out some sort of gimped HTTP API built on that work, which won't run simultaneously with the touch-screen user interface on the camera, I would very roughly estimate "late January" for basic HTTP control. This should not include video streaming, but should include video download and basic file management.
❷ I am continuing work on the new back-of-camera user interface. I've spent the last two weeks working on one of the two great unknowns of the process, jog wheel input. The other great unknown, the software keyboards, I will start work on tomorrow. I don't know how long the software keyboards will take. They could take a few days, or they could take a few weeks. The jog wheel still needs roughly a week or two of work, as each widget needs its own behaviour implemented. (Menus are going to become a heck of a lot easier to select.
)❸ Foobar has effectively ported the current UI forward to our shiny new Debian-based operating system. This is a major milestone for us! It means we can abandon our old operating system, which was sucking up a lot of our time. It also means we can do a more piece-wise release of the new features as they're built out, so we may see useful parts of the HTTP API available well before the full HTTP API is finished.
Attachments
hungkhungbo
New member
In the software update roadmap I do not see audio recordings for the video, what's going on? It looks like this feature will be available on version 1.0 ?