Messages

1

Chronos User Discussion / Re: Chronos 2.1 Technical Details

« on: April 06, 2019, 09:42:14 PM »

In the tear down video at 4:17 (https://youtube.com/watch?v=T4iBiVZlzns&t=4m17s) he says they actually took all the demo footage on the LUX8M, which is a higher resolution imager, though it also claims a 700,000+ max FPS, suggesting it has equal speed per line, just more pixels available. Total throughput seems to remain fixed, thus the reduced full frame rate FPS, but since they clearly have suggested they can simulate the LUX2100 expected performance with it, if light quantity isn't a problem (1/4 the pixel area of the 2100, so 4x more light needed for a given exposure time - this is the stuff they were talking about for noise in the footage), seems like it could be a good option for some.

2

Chronos User Discussion / Re: Chronos 2.1 Technical Details

« on: April 06, 2019, 06:11:07 PM »

About the weird 1920x8:

I suspect you're righ - that the sensor has a fixed readout stage of the full sensor width that it's the bottleneck for the max frame rate, especially since "700,000+" max rate is conveniently ~8x the 8 line speed - but since I don't have access to the full data sheet, I can only speculate and ask for confirmation.

go with maximum image quality.

That's one of the reasons I asked about the potential for a LUX8M model. 250FPS is plenty fast for many things, and even if it maxes at half the speed of the LUX2100 (again, no datasheet), that'd still be faster than the Chronos 1.4.

Ultimately, just trying to get a better feel for the actual limitations of the system

3

Chronos User Discussion / Re: Introducing Chronos 2.1 HD!

« on: April 05, 2019, 04:42:27 PM »

Not sure if it would be better to repost questions, or just link them, so I'll just link them for now:
http://forum.krontech.ca/index.php?topic=463.0

4

Chronos User Discussion / Re: Chronos 2.1 Technical Details

« on: April 05, 2019, 04:41:00 PM »

Looks like one of the answers was posted in the pinned annoucement and attached datasheet:

maximum frame rate of 100,000 FPS

which appears to be at 1920x8 (sensor datasheet says "125,000+ FPS @ 1920 × 8", so lost some speed somewhere in the pipeline)

Most of the resolutions posted are 1920 wide. Will there be support for partial width? 128x120 would be the same number of pixels as a 1920x8, and could be more useful in some circumstances, but perhaps there's a hardware limitation preventing this?

5

Chronos User Discussion / Chronos 2.1 Technical Details

« on: April 05, 2019, 11:42:22 AM »

Chronos 2.1 demo footage looks awesome! However, after watching the overview video, I had some questions.

The LUX2100 product brief claims 700,000+ FPS, but the Chronos 1.4's sensor claims 1,000,000 FPS (@1280x1), so I'm a bit skeptical of the camera's actual capability. What is the max FPS the Chronos 2.1 will likely support, and at what resolution? Better yet, do you have a table like you do for the Chronos 1.4?

Is the "2.1" numbering due to an increase in throughput (e.g. 2.1Gpx/s), a reference to the LUX2100 being a 2.1Mpx imager, or something else?

Will you be offering a version of the Chronos 2.1 that uses the LUX8M for people who want the extra spatial resolution, since you apparently already have the drivers working for it?

I thought about emailing my questions, but figured others would have them too, so posting instead

6

Software Dev / Re: Updating the UI: Input Methods Edition

« on: May 29, 2018, 09:38:55 PM »

Lots of input about scrollwheel UI here: https://forum.krontech.ca/index.php?topic=88.0

7

Software Dev / Re: Improving the Jog Wheel, ideas.

« on: May 29, 2018, 09:32:32 PM »

A good point of reference for jog wheel on hardware is the oscilloscope. It's been a standard input there for decades now, both for manipulating values and navigating menus. Some oscilloscope standards don't make as much sense for the camera (e.g. knob press to go to trigger time), but press to toggle/change selection and/or scroll speed both seem like natural UI options.

Press+hold is generally unwieldy, so I'm against that, but I could be on board with a long-press to open a meta-selection menu, then long press to exit selection menu. For navigating a video, for example, a long press would bring up a menu showing different speed selections you can choose from, but short pressing would immediately toggle between 2 (or the proposed 4). That would allow you to have some "quick" options, but also choose from all the options with minimal extra hassle.

As for the issue of #frames vs %buffer, in StepMania, speed is controlled in two ways that are directly comparable: fractions of the default, and constants/fixed speeds. Rather than offering a fixed number of both types, they instead let you select the mode type and number independently, kind of like units. So for the camera, you could be in 1 Frame mode, then change the units to % and now you're knob moves 1% of the buffer each click instead. This means your UI only needs 2 input fields to cover every possible combination.

I'm definitely not saying we should model everything after oscilloscopes or dance video games, but rather trying to provide examples where these sorts of problems also exist, and how their solutions might help inform the design for the camera.