46
Software Dev / Re: Software Roadmap - 0.3.1, 0.4.x, etc.
« on: August 03, 2018, 11:48:08 PM »
ooo, if you could do that, that would be great. It would be great to have one known option, regardless of what happens. 
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.
47
Software Dev / Re: Software Roadmap - 0.3.1, 0.4.x, etc.
« on: August 01, 2018, 03:57:25 PM »
Small update - after about a month of work, we've got all our core requirements compiling for our hardware architecture. This vastly increases certainty that my last three months of work will actually... work. 
Next step is to see if this can be copied to the camera and run. Will it pick up and use the Framebuffer?
Next step is to see if this can be copied to the camera and run. Will it pick up and use the Framebuffer?
48
Software Dev / Re: Software Roadmap - 0.3.1, 0.4.x, etc.
« on: August 01, 2018, 03:12:23 PM »When it comes to the "basic remote control", will that be via Ethernet and an app you will provide?
Will the initial implementation of that effectively allow us to use the Chronos 'tethered', so we can effectively start, stop, save, play clips and see the camera's live output remotely on a laptop?
Yes. The initial version of the basic remote control will be via Ethernet. Visiting the camera's network address from a laptop or cellphone will bring up a basic web-based UI. It will support start/stop/save and live video display. It should support playback of saved files as well. You may make your own HTTP API calls as well if you want to write scripts to control the camera.
If we can find a wireless USB dongle for sale that is supported by Debian 7, then wireless remote control will work as well. We haven't found a compatible dongle yet, the ones which do work are no longer for sale. However, something may yet turn up.
One feature I would love to see implemented is having shutter speed (EXPOSURE) in 1/60 1/100 1/500 1/1000 1/XXX instead of it being in Micro Seconds (us) as an option.
… That is an excellent suggestion. I've added it to the mockup for the new UI, so it should make it into 0.4.0.
49
Software Dev / Re: Software Roadmap - 0.3.1, 0.4.x, etc.
« on: July 31, 2018, 06:01:29 PM »
It is a thing that we would like to play with in the future, after 0.5. There's a handful of stuff like that we'd like to do at some point.
50
Software Dev / Software Roadmap - 0.3.1, 0.4.x, etc.
« on: July 31, 2018, 05:35:13 PM »
What is happening with the Chronos' software? What is in the works, and when will it be available?
Keeping in mind "The best laid plans of mice and men will often go awry", here's what we have planned:
Behind the scenes, the main delay is that we've discovered that it's impractical to continue development using our current operating system, Arago Linux. It lacks some basics such a C compiler, a scripting language, and several basic Linux debugging utilities. Arago's video subsystem also crashes after saving 45 videos.
For example, developing the back-of-camera user interface using Arago entails a ~5-minute delay between making a change and seeing the change in the UI. Using Debian, changes made to the UI are live in seconds.
We've been working on getting Debian running, on and off, for the past year. However, a few months ago a combination of near-success and issues with Arago's video system meant we decided to officially devote engineering time to the problem. This, naturally, delayed the progress we were making on the internal D-Bus API for 0.4.0, because now we were working on something else.
Currently, from my user-interface-centric perspective, here is how our progress is looking for version 0.4.0. The new UI and APIs will be debuted when this is complete.
tap for full resolution ↗️
Green means "completed", yellow is "in progress". Arrows show what depends on what. For example, the final implementation on the right depends on the D-Bus API, which has had the video control component made, and the D-Bus API Mock, which is currently being developed. Implementation is done by adding behaviour to a laid-out UI (labelled "Shell & Nav"), which I sketch up in Designer as a separate step. Each screen can be done more or less independently.
I hope this helps clear things up. I'll try to keep this thread updated as things progress. One of the big reasons we don't like to announce things is that they frequently turn out to simply be untrue. For example, we thought we'd fixed raw save speed, but then it turned out we hadn't a few times. We really don't want to promise something we won't deliver on, so we keep to ourselves quite frequently. What are your thoughts on this?
Keeping in mind "The best laid plans of mice and men will often go awry", here's what we have planned:
- 0.3.1 (expected late August)
- Improved image demosaic for .mp4 (less colour-fringing around high contrast areas)
- Overlay frame number on video.
- Save .dng for raw video.
- HDMI port supports video out.
- Basic remote video control. (play, pause, seek)
- Save more than 45 videos.
- Possible raw video save speed increase.
- Additional minor bugfixes and tweaks.
- 0.3.x (expected mid-September)
- Power controls (turn on when connected to power, turn off when not)
- Basic overlay controls. Maybe.
- 0.4.0 (expected late October)
- Debian replaces Arago as the camera operating system.
- Python is available to script the camera.
- External HTTP API available for custom scripting. (may be delayed)
- Internal D-Bus API available for custom scripting. (may be delayed)
- UI is ported to Python, prettied up, and made to use the D-Bus API.
- 0.4.1
- Bugfix release for 0.4.0.
- APIs, if delayed.
- 0.5.0
- Remote control app, using the HTTP API.
Behind the scenes, the main delay is that we've discovered that it's impractical to continue development using our current operating system, Arago Linux. It lacks some basics such a C compiler, a scripting language, and several basic Linux debugging utilities. Arago's video subsystem also crashes after saving 45 videos.
For example, developing the back-of-camera user interface using Arago entails a ~5-minute delay between making a change and seeing the change in the UI. Using Debian, changes made to the UI are live in seconds.
We've been working on getting Debian running, on and off, for the past year. However, a few months ago a combination of near-success and issues with Arago's video system meant we decided to officially devote engineering time to the problem. This, naturally, delayed the progress we were making on the internal D-Bus API for 0.4.0, because now we were working on something else.
Currently, from my user-interface-centric perspective, here is how our progress is looking for version 0.4.0. The new UI and APIs will be debuted when this is complete.
tap for full resolution ↗️
Green means "completed", yellow is "in progress". Arrows show what depends on what. For example, the final implementation on the right depends on the D-Bus API, which has had the video control component made, and the D-Bus API Mock, which is currently being developed. Implementation is done by adding behaviour to a laid-out UI (labelled "Shell & Nav"), which I sketch up in Designer as a separate step. Each screen can be done more or less independently.
I hope this helps clear things up. I'll try to keep this thread updated as things progress. One of the big reasons we don't like to announce things is that they frequently turn out to simply be untrue. For example, we thought we'd fixed raw save speed, but then it turned out we hadn't a few times. We really don't want to promise something we won't deliver on, so we keep to ourselves quite frequently. What are your thoughts on this?
51
Software Dev / Re: Updating the UI: Main Screen Edition
« on: July 26, 2018, 06:31:44 PM »
Well, I can't leave anything alone, so I've whipped up a ~modern touch display~ version. (It's based loosely on Krita's radial menu style.) I think it looks pretty, but it's also kind of mysterious what things do.
Tap anywhere on screen to bring up the radial menu. Buttons are the same as mockup 8, and do the same thing. Tapping the resolution in the corner brings up the list of presets, because it might as well.
I personally think it looks good, and it makes much better use of the screen space for image preview, but I don't like icon-only navigation which I think is confusing. I think zooming in on the video will help fix the focus issue we've got now, which is the main reason we wanted to make better use of the screen space in the first place.
Tap anywhere on screen to bring up the radial menu. Buttons are the same as mockup 8, and do the same thing. Tapping the resolution in the corner brings up the list of presets, because it might as well.
I personally think it looks good, and it makes much better use of the screen space for image preview, but I don't like icon-only navigation which I think is confusing. I think zooming in on the video will help fix the focus issue we've got now, which is the main reason we wanted to make better use of the screen space in the first place.
52
Software Dev / Re: Updating the UI: Main Screen Edition
« on: July 25, 2018, 05:25:13 PM »
Let's roll with V8 then. 
53
Software Dev / Re: Updating the UI: Main Screen Edition
« on: July 23, 2018, 07:49:00 PM »
OK, time to perform some thread necromancy here and revive this topic. Design requirements have changed somewhat with the addition of soft buttons.
First up, we have the upper row of (fixed) buttons replaced by soft buttons. I'm thinking these should default to Recording Settings, Trigger/IO, Trigger Delay, and Prefs & Utils. However, as we see people use the camera, we will refine these defaults. I don't really know how they will be used at the moment.
The soft buttons would be configured in the utils menu, and perhaps by long-tap. (Long taps are terrible to discover, so there needs to be a backup. And no one reads the manual.
)
Mockup 7:
The buttons along the side now slide out menus. Tapping a button will slide the entire right panel to the left to make room for the opened panel. This means your finger is over whatever you're about to tap on, but it does mean muscle memory is somewhat more situational than it was. The alternative is to pop the opened panel up to the left (or on top of) of the exposure slider. Less prone to accidental clicks, and nothing has to move around.
The buttons are mapped as follows:
Mockup 8:
As an alternative to having default soft buttons, we could have no soft buttons at all until they are configured in the Utils screen. This makes the main screen design less cluttered when the camera is first encountered, and gives a bit more room for video to be displayed.
As a side note, in the future soft buttons could be extended to include the vertical column of buttons as well as the top row. You'd probably have a list of options and configurations they could activate, and by checking them you could build up a menu. There's quite a lot of possibility here. Perhaps long-tapping on any button lets you select it as a soft button? Perhaps the entire home screen could be surrounded by soft buttons if you wanted. Perhaps there could be multiple, customizable screens.
Schedule-wise, the first mockup, mockup 7, may make it into the initial release of the new UI. However, anything else will have to come later due to time constraints.
As always, please let me know what you think. Your feedback has a huge influence on the design of the Chronos UI!
First up, we have the upper row of (fixed) buttons replaced by soft buttons. I'm thinking these should default to Recording Settings, Trigger/IO, Trigger Delay, and Prefs & Utils. However, as we see people use the camera, we will refine these defaults. I don't really know how they will be used at the moment.
The soft buttons would be configured in the utils menu, and perhaps by long-tap. (Long taps are terrible to discover, so there needs to be a backup. And no one reads the manual.
)Mockup 7:
The buttons along the side now slide out menus. Tapping a button will slide the entire right panel to the left to make room for the opened panel. This means your finger is over whatever you're about to tap on, but it does mean muscle memory is somewhat more situational than it was. The alternative is to pop the opened panel up to the left (or on top of) of the exposure slider. Less prone to accidental clicks, and nothing has to move around.
The buttons are mapped as follows:
- Preferences& Utilities: Open up the preferences window as before. Since this window is complex enough as is, I don't think it should be hidden behind a menu.
- Recording & Triggers: Opens up a panel with buttons to open trigger io settings, trigger delay, record modes, and record settings.
- Shot Assist: Similar to the mockup attached in the first post, this dialog lets you configure focus aid as well as enable zebra stripes.
- Calibration: Set white balance and perform black cal. on colour models. If you have a black-and-white model, this calibration menu will be replaced with the black cal button.
Mockup 8:
As an alternative to having default soft buttons, we could have no soft buttons at all until they are configured in the Utils screen. This makes the main screen design less cluttered when the camera is first encountered, and gives a bit more room for video to be displayed.
As a side note, in the future soft buttons could be extended to include the vertical column of buttons as well as the top row. You'd probably have a list of options and configurations they could activate, and by checking them you could build up a menu. There's quite a lot of possibility here. Perhaps long-tapping on any button lets you select it as a soft button? Perhaps the entire home screen could be surrounded by soft buttons if you wanted. Perhaps there could be multiple, customizable screens.
Schedule-wise, the first mockup, mockup 7, may make it into the initial release of the new UI. However, anything else will have to come later due to time constraints.
As always, please let me know what you think. Your feedback has a huge influence on the design of the Chronos UI!
54
Software Dev / Re: Updating the UI: Output Stamping (data, watermark on final video)
« on: July 23, 2018, 06:50:02 PM »
Hm.
That's actually a really good idea. We've been considering splitting the UI into two versions - one for point-and-shoot use, and one for scientific and engineering use which would expose every number and option we could think of. I'd slotted each mockup into one category. Now that you mention it, I actually quite like the idea of having a simple and detailed view. I think it makes a lot of sense in this case. I was kind of blinded by my categories.
That's actually a really good idea. We've been considering splitting the UI into two versions - one for point-and-shoot use, and one for scientific and engineering use which would expose every number and option we could think of. I'd slotted each mockup into one category. Now that you mention it, I actually quite like the idea of having a simple and detailed view. I think it makes a lot of sense in this case. I was kind of blinded by my categories.
55
Software Dev / Re: Updating the UI: Battery
« on: July 20, 2018, 05:11:53 PM »If you do that, then please also add an Option to turn off all those sounds as well, since some People (Like me) maybe dont like to have them.Absolutely! That's always one of the first things I do when I get a new device too.
56
Software Dev / Re: Updating the UI: Output Stamping (data, watermark on final video)
« on: July 20, 2018, 05:07:02 PM »
Thanks!
I agree, we should have a way to format the output of time. I'll have to play around with the formatting a bit, when I've implemented the input for it. ... Something I'd like to do would be to add the %-specifiers to a list you could scroll through while entering the text, so you can see what's actually available without having to look it up in the manual. I don't know if I can justify it though, this is the only place I'd really use it at the moment.
I agree, we should have a way to format the output of time. I'll have to play around with the formatting a bit, when I've implemented the input for it. ... Something I'd like to do would be to add the %-specifiers to a list you could scroll through while entering the text, so you can see what's actually available without having to look it up in the manual. I don't know if I can justify it though, this is the only place I'd really use it at the moment.
57
Software Dev / Updating the UI: Motion trigger configuration
« on: July 19, 2018, 07:53:24 PM »
In a previous post, some time ago, I'd drawn up a revised triggers screen. I've produced a revised version for (hypothetical) motion triggering.
Trigger action screen:
Most of the modifiers for the electrical triggers don't apply any more, so they've been removed. A live preview of the motion trigger area has been added in. The active area can be dragged around like on the recording settings screen. Clicking the Configure button below it brings us to the motion trigger configuration screen.
Motion Trigger Configuration
Instead of describing how the motion trigger configuration screen works, I'd like to hear how you think it should work. Most people will be coming to this screen without foreknowledge when they're using the camera. First impressions matter!
Trigger action screen:
Most of the modifiers for the electrical triggers don't apply any more, so they've been removed. A live preview of the motion trigger area has been added in. The active area can be dragged around like on the recording settings screen. Clicking the Configure button below it brings us to the motion trigger configuration screen.
Motion Trigger Configuration
Instead of describing how the motion trigger configuration screen works, I'd like to hear how you think it should work. Most people will be coming to this screen without foreknowledge when they're using the camera. First impressions matter!
58
Software Dev / Updating the UI: Output Stamping (data, watermark on final video)
« on: July 19, 2018, 05:32:12 PM »
One of the more often requested features for the Chronos is the ability to see exact timing information, so you can figure out when an event occurred relative to a trigger. This is especially useful for trigger modes where the framerate may not be consistent, such as with shutter gating.
I've designed two screens. The first and the simplest is what I'm intending to include in the initial version of the redesigned UI. I think it covers most of the use-cases, and it's a lot simpler to implement.
(I'm not sure why the arrows on the number inputs got rendered as "a"s. They should just be up/down wedges. 🤷)
The second is a more advanced screen, which exposes more of the hardware capabilities. It would only be useful if we had more than three options, or if there were a solid use-case for having the flexibility to format timing and frame count.
The %percent-key% format would let you burn metadata into the video for easy consumption, since not every video player displays metadata so well. (eg., the pictured "Trg: %TimeFromTrigger%" would actually print something like "Trg: +204515.1ns" in the corner of a saved frame of video.) If in the future we capture metadata on a per-frame basis, then we'll have a bunch of fields which would be quite amenable to this interface.
In both screens, images are pulled from the root folder of a USB stick you insert. (We might get a proper file-browser some day, as part of an on-camera footage management and review system.)
As always, please let me know your thoughts on the matter. If I've missed anything you would find important, now is the best time to let me know.
I've designed two screens. The first and the simplest is what I'm intending to include in the initial version of the redesigned UI. I think it covers most of the use-cases, and it's a lot simpler to implement.
(I'm not sure why the arrows on the number inputs got rendered as "a"s. They should just be up/down wedges. 🤷)
The second is a more advanced screen, which exposes more of the hardware capabilities. It would only be useful if we had more than three options, or if there were a solid use-case for having the flexibility to format timing and frame count.
The %percent-key% format would let you burn metadata into the video for easy consumption, since not every video player displays metadata so well. (eg., the pictured "Trg: %TimeFromTrigger%" would actually print something like "Trg: +204515.1ns" in the corner of a saved frame of video.) If in the future we capture metadata on a per-frame basis, then we'll have a bunch of fields which would be quite amenable to this interface.
In both screens, images are pulled from the root folder of a USB stick you insert. (We might get a proper file-browser some day, as part of an on-camera footage management and review system.)
As always, please let me know your thoughts on the matter. If I've missed anything you would find important, now is the best time to let me know.
59
Software Dev / Re: Remote power on
« on: July 19, 2018, 03:39:48 PM »
We're aiming to have "wake on power" available through the planned battery/power screen. It'll start the camera when power is supplied. When we release the planned HTTP API, you'll be able to use that to turn off the camera remotely, as well as just unplugging it. Unfortunately, there will never be a 'turn camera on' api call, due to the logistics of the situation.
Hope that helps!
Hope that helps!
60
Software Dev / Re: Updating the UI: Battery
« on: July 19, 2018, 03:21:15 PM »What's Voltage vs Charge? What is each trying to tell me?Nikon1 is correct.
Does the regular user need both?No. The electrical engineers around the office wanted it though.
It might be useful to determine battery issues when things go wrong.
Looks great so far. Can we also please get an audible alarm on low battery? I know there's a speaker in the chronos.That seems reasonable. I should probably add a visual warning to the main screen, too, now that you mention it.
I'd love to add in more "little sounds" to the UI, like a little click when pressing a button.