1
Software Dev / Re: Chronos V0.5.0 Full Release
« on: August 04, 2020, 06:15:16 PM »
Must say, I love what you did with the interface. Very nice! 
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
Software Dev / Re: Save Frame rate value to file
« on: December 06, 2019, 12:06:13 PM »
Hi ptrautne!
If you save the video as DNG or TIFF, the source framerate will get encoded in the EXIF data as Exif.Image.FrameRate (tag number 51044). You can set this option in the save settings screen, in the playback window. (p11-12 in v0.3.2 of the manual)
All the best,
–DDR
If you save the video as DNG or TIFF, the source framerate will get encoded in the EXIF data as Exif.Image.FrameRate (tag number 51044). You can set this option in the save settings screen, in the playback window. (p11-12 in v0.3.2 of the manual)
All the best,
–DDR
3
Software Dev / Re: Updating the UI: Main Screen v2 + Dark Theme
« on: September 30, 2019, 03:06:15 PM »Regarding gestures:
They can be very handy. But often aren't intuitive, and nobody reads the manual.
Would it be possible to add a "hint wheel" (no idea how you would call it...)?
I toyed around with a design for one a while back, but it never gained any serious traction.
I do think it would be much better off with the rest of the UI as it stands now, instead of on it's own as it was.
I had a bit of a re-read through Pie Menus: A 30 Year Retrospective, which is a wonderful dive into the subject. Pie menus still pretty uncommon, especially on cameras like the Chronos, so I'm hesitant to put them in. But on the other hand, they're perfect for the task.
4
Software Dev / Re: Updating the UI: Main Screen v2 + Dark Theme
« on: September 26, 2019, 03:30:26 PM »I'm not a fan of hard to discover features either but since Android does it and is very widespread I presumed people already know the swipe down thing, but I can be wrong.
Hm. You're right, I should probably put it in there if I can. I don't think it'll hurt anything, and having things respond the way you're used to is nice. It's also the way the Blackmagic camera we have here works, so some might be used to it. I don't like the feel their implementation though, tbh, so I'll have to figure out why and see if we can do better.
As for the customisation, I think having disable/enable and the menu sizes is a very good start. I'll put that in the initial version.
5
Software Dev / Re: Updating the UI: Main Screen v2 + Dark Theme
« on: September 24, 2019, 05:42:58 PM »
Thanks for the feedback, everyone!
Having a tap on the video image toggle full-screen could work well.
I personally find swipe and most multitouch gestures quite hard to discover, since there's no good way to visually indicate what gesture will have the desired effect. Pinch to zoom and drag to move are the only exceptions, since they're reasonably intuitive and very common.
I know in the current UI, we had one internal release where the UI auto-hid after a few seconds of inactivity. It never made it to full release, because the auto-hiding had to be disabled because there were a lot of complaints about it. I've also had a lot of requests for some sort of a countdown timer so you know when you run out of memory, so I think that should probably be always-active.
Unfortunately, the UI has to be a bit of a jack of all trades I think. It will end up getting used by students, researchers, enthusiasts, and (hopefully) by folk in the film and television industry. This represents a very wide skill range! What's suitable for a beginner student - detailed, explicit controls - is not suitable for an expert enthusiast who may want to trade explicitness for density and ease of access to many functions.
I think a good solution would be to have the more explicit UI with the full text by default, but be able to fully configure the main screen in terms of geometry and content. The problem is that this is actually quite difficult to program in, since I think we would want a graphical editor with drag and drop, and all that sort of nice interaction. I'm certainly up for putting such a thing in, but I'd like to get an initial release out the door first.
In the current version of the interface, there's a difference between the physical record button and the touch-screen one. I've unified them in this design, which I hope will work because the current situation is rather confusing. The jog wheel can control everything in the new design too, so you shouldn't ever actually need to use the touch-screen. (I'd love to add more hardware buttons - but that adds more cost and complexity.)
I'd like to. I think it should be possible without too much trouble, with the current tech stack. You're not the only person to request it, and I think the light version works quite a bit better in really well-lit environments. 🙂
Maybe add an option to make the bars disappear and re-appear when swiping (like on the Android OS for example).
Maybe make the toolbars translucent so the image is visible, full-screen, behind them (see new iOS camera app)? Also allow users to "pin" one or both toolbars on screen, else they [fade to 50%? fade to 0%? auto-hide? compress down to one text line each?] until the next touch event. Personally I never really want any data on the screen while recording, it's not useful in that moment, should be hidden until needed.
- bigger Buttons are usually a good thing, but they should not intrude on the actual picture. There are a few obvious answers to this dilemma:
- Hide the UI if not needed
- Provide the most needed or customizeable buttons on the main screen and hide others in menues
- provide hardware buttons instead of or in addition to software ones (like the record button, use of the encoder knob where applicable etc)
Having a tap on the video image toggle full-screen could work well.
I personally find swipe and most multitouch gestures quite hard to discover, since there's no good way to visually indicate what gesture will have the desired effect. Pinch to zoom and drag to move are the only exceptions, since they're reasonably intuitive and very common.I know in the current UI, we had one internal release where the UI auto-hid after a few seconds of inactivity. It never made it to full release, because the auto-hiding had to be disabled because there were a lot of complaints about it. I've also had a lot of requests for some sort of a countdown timer so you know when you run out of memory, so I think that should probably be always-active.
Unfortunately, the UI has to be a bit of a jack of all trades I think. It will end up getting used by students, researchers, enthusiasts, and (hopefully) by folk in the film and television industry. This represents a very wide skill range! What's suitable for a beginner student - detailed, explicit controls - is not suitable for an expert enthusiast who may want to trade explicitness for density and ease of access to many functions.
I think a good solution would be to have the more explicit UI with the full text by default, but be able to fully configure the main screen in terms of geometry and content. The problem is that this is actually quite difficult to program in, since I think we would want a graphical editor with drag and drop, and all that sort of nice interaction. I'm certainly up for putting such a thing in, but I'd like to get an initial release out the door first.
- provide hardware buttons instead of or in addition to software ones (like the record button, use of the encoder knob where applicable etc)
In the current version of the interface, there's a difference between the physical record button and the touch-screen one. I've unified them in this design, which I hope will work because the current situation is rather confusing. The jog wheel can control everything in the new design too, so you shouldn't ever actually need to use the touch-screen. (I'd love to add more hardware buttons - but that adds more cost and complexity.)
- Please add the ability to select a color theme (light / dark)
I'd like to. I think it should be possible without too much trouble, with the current tech stack. You're not the only person to request it, and I think the light version works quite a bit better in really well-lit environments. 🙂
6
Software Dev / Updating the UI: Main Screen v2 + Dark Theme
« on: September 23, 2019, 06:47:09 PM »
Hello, everyone. With the new UI almost finished here, I've had time to go back and revisit the main screen design from last year. Updating the UI: Main Screen Edition) was one of the first things that I designed. I'm not satisfied with it any more, I think we can do better.
The new screen is much closer to the industry standard of "two bars, top and bottom". It is also light-on-dark, instead of the old dark-on-light colour scheme we had been running with before.
There doesn't seem to be any major difference in readability between the dark and the light version of the UI, although living in Vancouver I haven't been able to test in direct sunlight yet.
Each control, starting from top-left, works as follows:
I have attached a picture of the mockup on the camera, to give a sense of scale. In person, the colours generally darker, more saturated, and less aggressively blue. (But my thumb looks great!)
A lower-profile version is also under consideration. It gives 40px more vertical resolution to the picture, taking the total vertical resolution from 360px to 400px. (The screen itself is 480px tall by 800px wide.)
While this actually does work fine, it does squish the spectrogram and some of the labelling around play/save is lost. I prefer the chunkier UI, as it's a bit easier to read and a bit easier to tap. If we do decide to use this thinner UI, we would probably make a large spectrogram an overlay on the main screen, toggled by the smaller spectrogram button.
As always, feedback is welcome! For example, would you prefer the denser, lower-profile bars instead of the chunkier ones? Do you prefer the sidebar style of the first iteration, as it matches up with the Chronos 1.4's aspect max-resolution ratio better? What do you think of the dark colour-scheme?
Updating the UI: Main Screen Edition) was one of the first things that I designed. I'm not satisfied with it any more, I think we can do better.The new screen is much closer to the industry standard of "two bars, top and bottom". It is also light-on-dark, instead of the old dark-on-light colour scheme we had been running with before.
There doesn't seem to be any major difference in readability between the dark and the light version of the UI, although living in Vancouver I haven't been able to test in direct sunlight yet.
Each control, starting from top-left, works as follows:
- Menu - Opens a drop-down list of all the screens of the camera, to access detailed functionality not on the main screen. Filterable by text, respecting most synonyms.
- Audio levels monitor - Tap to open audio trigger configuration. Also shows audio trigger if set up. (Not shown.)
- Battery - Tap to open power settings. Will turn red at 15% over save-and-power-down limit, will pulse red at 5% unless plugged in.
- Save Media - Tap to open the file settings screen, to configure where files are saved to.
- Play / Save - Tap to open an analogue of the current play and save screen. Select which region(s) of RAM to save to file.
- Record - Start/stop a recording. Background will show recorded video in RAM as a motion heatmap in the future as pictured, if possible, as well as showing segments during segmented record mode.
- The Picture In The Middle - Pinch to zoom.
- Resolution - Tap to open the window to set resolution, framerate, and exposure.
- Exposure - Tap to bring up the exposure slider, as on the current main screen, and to switch between shutter angle, percent, and duration readout.
- Spectrogram - Tap to bring up white balance screen on colour models. The spectrogram itself will be added in the future, if possible. Until then, it will be a placeholder button reading "white balance".
- Black Cal - Tap to perform black calibration, as on the current main screen.
- Zebra Stripes - Highlight white, as on the current main screen.
- Focus Peaking - Highlight areas of high contrast, as on the current main screen. Tap the red square to select peaking colour. (Square will show new colour.)
I have attached a picture of the mockup on the camera, to give a sense of scale. In person, the colours generally darker, more saturated, and less aggressively blue. (But my thumb looks great!)
A lower-profile version is also under consideration. It gives 40px more vertical resolution to the picture, taking the total vertical resolution from 360px to 400px. (The screen itself is 480px tall by 800px wide.)
While this actually does work fine, it does squish the spectrogram and some of the labelling around play/save is lost. I prefer the chunkier UI, as it's a bit easier to read and a bit easier to tap. If we do decide to use this thinner UI, we would probably make a large spectrogram an overlay on the main screen, toggled by the smaller spectrogram button.
As always, feedback is welcome! For example, would you prefer the denser, lower-profile bars instead of the chunkier ones? Do you prefer the sidebar style of the first iteration, as it matches up with the Chronos 1.4's aspect max-resolution ratio better? What do you think of the dark colour-scheme?
7
Software Dev / Re: Software Roadmap - 0.3.1, 0.4.x, etc.
« on: June 06, 2019, 05:16:21 PM »
Work continues. About half the stuff we need to expose via the API has been exposed, but the UI has been delayed as I've been busy trying to work out some nasty performance issues.
(click to enlarge)
(click to enlarge)
8
Software Dev / Re: Software Roadmap - 0.3.1, 0.4.x, etc.
« on: May 01, 2019, 02:58:20 PM »
Well, we're back from NAB with the Chronos 2 and the bullet-time Ring announced and successfully demoed! We're turning our attention to the camera control APIs now.
Good news/bad news: The good news is that there's actually some serious progress being made on the API - it has basic working control of the cameras, can set resolution, and take and save recordings. The bad news is that it's not the original API I had designed when I made the new UI, since the new API was developed as part of the Ring project.
Here's the current status of the API and UI:
(click to enlarge)
From left to right, we have:
Most of the screens' implementations have been demoted to being "in progress", since I need to go back and change the API calls being made in all the screens I had wired in. In some cases, this is simply a matter of using a new name. In other cases, such as the recording settings screen, the API works quite differently and the screen will have to be significantly reworked.
We're still aiming to release the initial version of the API in June, so you all can give us feedback and start automating your camera!
Good news/bad news: The good news is that there's actually some serious progress being made on the API - it has basic working control of the cameras, can set resolution, and take and save recordings. The bad news is that it's not the original API I had designed when I made the new UI, since the new API was developed as part of the Ring project.
Here's the current status of the API and UI:
(click to enlarge)
From left to right, we have:
- Shell & Nav: Complete, I've designed and imported all the planned screens into the new UI's code. This is still good to go.
- Implementation (Front-End): This is the back-of-camera interface redesign I've been working on. It makes the camera do stuff by telling the internal D-Bus API to do stuff.
- Implementation (D-Bus APIs, v2): Turns commands from the back-of-camera interface and the HTTP API into lower-level commands to the components of the camera, such as the field-programmable gate array or the image sensor.
Most of the screens' implementations have been demoted to being "in progress", since I need to go back and change the API calls being made in all the screens I had wired in. In some cases, this is simply a matter of using a new name. In other cases, such as the recording settings screen, the API works quite differently and the screen will have to be significantly reworked.
We're still aiming to release the initial version of the API in June, so you all can give us feedback and start automating your camera!
9
Software Dev / Re: Control the camera from a pc
« on: March 11, 2019, 08:56:18 AM »
API news will be announced on this forum. The easiest way to stay up to date is probably by subscribing via RSS. (The links are at the bottom of the page.)
Development of the externally-facing APIs you need is open. The component for pc-based control is at https://github.com/krontech/chronos-web-interface. It's a HTTP-based API, which is a wrapper around two internal APIs. Those APIs are the coordinator api written in Python and the video api written in C. Neither are ready for use yet, so the http api you need doesn't work yet. The coordinator api only exists in mocked form and is (well?) [https://krontech.github.io/chronos-gui-2/D-Bus.html]documented. The video api, which actually works for realsies, is undocumented at the moment so you can't use it either.
We're hoping to have the APIs released by the end of June now. Previously, we were hoping to have them released by the end of last January.
For your second question, it sounds like setting a delay as you describe will do what you want.
Hope that helps!
Development of the externally-facing APIs you need is open. The component for pc-based control is at https://github.com/krontech/chronos-web-interface. It's a HTTP-based API, which is a wrapper around two internal APIs. Those APIs are the coordinator api written in Python and the video api written in C. Neither are ready for use yet, so the http api you need doesn't work yet. The coordinator api only exists in mocked form and is (well?) [https://krontech.github.io/chronos-gui-2/D-Bus.html]documented. The video api, which actually works for realsies, is undocumented at the moment so you can't use it either.
We're hoping to have the APIs released by the end of June now. Previously, we were hoping to have them released by the end of last January.
For your second question, it sounds like setting a delay as you describe will do what you want.
Hope that helps!
10
Software Dev / Re: Software Roadmap - 0.3.1, 0.4.x, etc.
« on: March 11, 2019, 08:31:36 AM »Any updates?No. >_<
This is quite frustrating all around, I think.
Most of the company has been pulled off into NAB prep. Since it's at the end of this month and we are not strictly speaking ready, that has been where the attention has been.
I myself have been splitting my time between NAB work and writing the documentation for the HTTP API. The documentation is nearing completion, the API is not. To that end, I'm going to announce the dummy API soon, in the hope of gathering some useful feedback. Most APIs are terrible, and I would like this one to be the exception. The real API will be available two or three months after NAB, hopefully.
Actually testing the next beta of the current software is almost done too, thanks to skronstein's efforts.
We hope to issue a release soon. One of the issues testing has turned up that we didn't know about is that we broke white balance at some point. It now makes whites less balanced instead of more balanced.I think the idea of the testing is that we will be able to release new betas without delaying for any new features or bugfixes, since we will know what is wrong. However, perfectionism dies hard. I will do what I can to make sure the release does happen, even with caveats such as broken white balance.
Sorry for the delays.
11
Software Dev / Re: Software Roadmap - 0.3.1, 0.4.x, etc.
« on: February 08, 2019, 12:00:40 PM »
Well, it's been a while since I updated what was going on behind the scenes here. While we've all been working hard, it's been a lot of behind-the-scenes sort of stuff. Nothing very showy, really.
So, some background is in order.
We decided about a year ago that we did not want to keep using the original version of the software, camApp, which ships with the camera and is updated via the betas on this forum. One of the main reasons for this is that we wanted a web api and remote control app. Embedding a web server in original camApp was impractical. An external web server could not reasonably be hacked together with the tools available¹. Some infrastructure needed to be built.
So, Foobar ported a newer linux kernel to our CPU, and we got access to much better tools. Porting a linux kernel is generally not considered a one-man job, so it took him a few months. During this time, I put together a virtual machine to develop the new UI, called gui2, on. After I'd completed that, Foobar promptly delivered an early version of the new linux to me. While it lacked drivers for all the camera-y parts, I was able to get a modern tech stack up and running and I used this to develop the app for the next half-year.
As this progressed, it became apparent that the tech stack I'd compiled was not one that we could safely upgrade and maintain. Foobar completed his port of the linux kernel, giving us Debian 8 as the underlying operating system, and we decided to backport the infrastructure I was using from Debian 9. This was completed, but we were still several versions behind what I'd developed the new UI on. I am currently finishing porting everything from my new tech stack to the older, maintainable versions of the tech we had. While a few bugs remain, I got the app running in it's entirety, on it's final tech stack, this afternoon.
Near the beginning of all this, Johan was hired to extract the startup logic from the current camApp. (I was hired to do the mobile app promised in the Kickstarter, which was deferred due to the technical issues mentioned above, so I wound up extracting the graphical user interface from the camApp.) Extracting the startup logic to initialize the sensor proved to be quite difficult. This was completed this morning, and the camera can now start and show the new UI entirely without having to run the current camApp!
The camera can now also run a nascent HTTP API, which plays well with the new UI. If you update a value via the API, the new value is reflected in the UI running on the camera. However, both the new UI and the alpha HTTP API are still largely disconnected from the hardware of the camera. They are running against dummy values. Since Johan has managed to bring up the camera, he is now implementing the dummy values so the HTTP API and the new UI can actually make changes to the camera. Some tasks are expected to be easy to tell the camera to do, while others will require a bit more work. This implementation is represented by box ❶ in the last progress chart posted in this thread³.
While all this has been going on, Loial has been making significant improvements to the firmware of the camera's FPGA. This has been appearing in the forum betas. We are currently in the midst of working on a testing plan for the next beta, since we'd like it to actually work this time. Unfortunately, there turns out to be quite a lot to our software, so while skronstein has been working on the testing plan it is still a work in progress. I myself may be pulled aside for a few days to complete that, so we can test and release next beta here. 🙂
If you'd like to talk to us in person and see some cool stuff, we'll be at NAB. It's April 6th through 11th in Las Vegas, though we'll be around a few days longer for setup and teardown.
¹ These tools were Ash² scripts being called via CGI.
² Ash is like Bash, but awful.
³ There has been no real progress on the chart since then since both Johan and myself have been been dealing with the underlying work of making our respective technologies run. Since this work was unforseen and unpredictable, it was uncharted.
So, some background is in order.
We decided about a year ago that we did not want to keep using the original version of the software, camApp, which ships with the camera and is updated via the betas on this forum. One of the main reasons for this is that we wanted a web api and remote control app. Embedding a web server in original camApp was impractical. An external web server could not reasonably be hacked together with the tools available¹. Some infrastructure needed to be built.
So, Foobar ported a newer linux kernel to our CPU, and we got access to much better tools. Porting a linux kernel is generally not considered a one-man job, so it took him a few months. During this time, I put together a virtual machine to develop the new UI, called gui2, on. After I'd completed that, Foobar promptly delivered an early version of the new linux to me. While it lacked drivers for all the camera-y parts, I was able to get a modern tech stack up and running and I used this to develop the app for the next half-year.
As this progressed, it became apparent that the tech stack I'd compiled was not one that we could safely upgrade and maintain. Foobar completed his port of the linux kernel, giving us Debian 8 as the underlying operating system, and we decided to backport the infrastructure I was using from Debian 9. This was completed, but we were still several versions behind what I'd developed the new UI on. I am currently finishing porting everything from my new tech stack to the older, maintainable versions of the tech we had. While a few bugs remain, I got the app running in it's entirety, on it's final tech stack, this afternoon.
Near the beginning of all this, Johan was hired to extract the startup logic from the current camApp. (I was hired to do the mobile app promised in the Kickstarter, which was deferred due to the technical issues mentioned above, so I wound up extracting the graphical user interface from the camApp.) Extracting the startup logic to initialize the sensor proved to be quite difficult. This was completed this morning, and the camera can now start and show the new UI entirely without having to run the current camApp!
The camera can now also run a nascent HTTP API, which plays well with the new UI. If you update a value via the API, the new value is reflected in the UI running on the camera. However, both the new UI and the alpha HTTP API are still largely disconnected from the hardware of the camera. They are running against dummy values. Since Johan has managed to bring up the camera, he is now implementing the dummy values so the HTTP API and the new UI can actually make changes to the camera. Some tasks are expected to be easy to tell the camera to do, while others will require a bit more work. This implementation is represented by box ❶ in the last progress chart posted in this thread³.
While all this has been going on, Loial has been making significant improvements to the firmware of the camera's FPGA. This has been appearing in the forum betas. We are currently in the midst of working on a testing plan for the next beta, since we'd like it to actually work this time. Unfortunately, there turns out to be quite a lot to our software, so while skronstein has been working on the testing plan it is still a work in progress. I myself may be pulled aside for a few days to complete that, so we can test and release next beta here. 🙂
If you'd like to talk to us in person and see some cool stuff, we'll be at NAB. It's April 6th through 11th in Las Vegas, though we'll be around a few days longer for setup and teardown.
¹ These tools were Ash² scripts being called via CGI.
² Ash is like Bash, but awful.
³ There has been no real progress on the chart since then since both Johan and myself have been been dealing with the underlying work of making our respective technologies run. Since this work was unforseen and unpredictable, it was uncharted.
12
Software Dev / Re: Software Roadmap - 0.3.1, 0.4.x, etc.
« on: January 23, 2019, 04:19:09 PM »
Hi JamesB.
I've asked around, and the backend guys have told me that saving/restoring black cal images would be "very hard". I'd like to see that feature myself — I've had a lot of difficulty around changing temperature and black cal — so I'm still going to push for it.
There was some unrelated work done to improve the vertical banding problem, however. It should land in either the next 0.3.x beta or 0.4.x, and should help that issue quite a bit.
I've asked around, and the backend guys have told me that saving/restoring black cal images would be "very hard". I'd like to see that feature myself — I've had a lot of difficulty around changing temperature and black cal — so I'm still going to push for it.
There was some unrelated work done to improve the vertical banding problem, however. It should land in either the next 0.3.x beta or 0.4.x, and should help that issue quite a bit.
13
Software Dev / Re: Software Roadmap - 0.3.1, 0.4.x, etc.
« on: January 17, 2019, 01:17:38 PM »
Hi Thomas. As it stands, @skronstein is working on a test plan for verification of 0.3.x. So that should be coming in a few weeks, once we've actually checked it does what we say it does. @tesla500 is working on an improved version of the power-down feature for your use. A more configurable version will be released with the new UI, on the power screen. I myself am busy with 0.5.x UI, which will be served by the API Johan is working on for 0.4.x. (We've experienced difficulty extracting the sensor initialization logic from the old camApp code.)
I hope that helps explain what we've been working on. There haven't been any major milestones to announce, so I'm afraid we've been pretty quiet.
I hope that helps explain what we've been working on. There haven't been any major milestones to announce, so I'm afraid we've been pretty quiet.
14
Chronos User Discussion / Re: Time Stamps
« on: January 02, 2019, 05:16:12 PM »
Hi all,
Thanks for the feedback. I'm glad to see the overlay is getting some use!
Going forward, the new UI I'm working on will have some minimal overlay configuration settings. It will be a small improvement over what we have now.
After the new UI is released, I'm planning to add fine-grained stamp settings. These will include the ability to choose a font (and thus font-size) and some formatting options for the data. Including what the timestamp and frame numbers are relative to.
Thanks for the feedback. I'm glad to see the overlay is getting some use!
Going forward, the new UI I'm working on will have some minimal overlay configuration settings. It will be a small improvement over what we have now.
After the new UI is released, I'm planning to add fine-grained stamp settings. These will include the ability to choose a font (and thus font-size) and some formatting options for the data. Including what the timestamp and frame numbers are relative to.
15
Chronos User Discussion / Re: Dual Cameras over Ethernet
« on: December 17, 2018, 04:24:36 PM »
Hi mcknight. You're right, you'll need to configure one of the cameras to use a different IP address than the other. To do this, edit the /etc/network/interfaces and /etc/udhcp.conf files on one of your cameras, changing 192.168.12.1 to 192.168.13.1. This should put the camera on a different subnet, which will keep them from fighting each other.
Hope that helps!
Hope that helps!