Messages

46

Chronos User Discussion / Re: EV Tables?

« on: July 06, 2017, 11:10:14 PM »

Thank you for the detailed response, I only just understand and follow that, it's quite confusing for someone who is new to cameras.

This is why I was hoping there could be a table drawn up(Maybe it could go in the manual) and would allow someone to do this without going through all those calculations to compare different combinations of things.

For example, I thought that the ISO changed depending on your shutter speed? Or is that an independent control again? Or linked with another option?

This sort of confusion is why the 'how to use a manual camera' crash course in the manual will be so handy!  I can fumble through a lot of it asking stupid questions, but being able to look up until I get a feel for it or after not using it for a while will be very handy.

47

Software Dev / Re: GPL Source Code

« on: July 06, 2017, 08:29:19 AM »

I'd love to be proven wrong, I've seen people both fork off and refuse to give back changes as well as very open and giving people. Planning for the worst, expecting the best.

I guess it depends on how the camera's internals are done. I mostly fail to see, unless I'm radically wrong about how the LGPL works(And the people who I talk to about this are all out of the country or out of contact for the next few weeks!), how having the camera's main software and libs under LGPL stops you from writing a big program that connects to everything through those APIs, from using the MIT license or even keeping your code to yourself completely.
After all, I'm running some very closed software(VMWare and Chrome with it's DRM libs to name two) on a very open OS(Debian) with no licence issues.

The only two 'serious' open camera projects I know of is https://www.apertus.org/ and https://www.elphel.com/
I'm going to assume that Chronos will allow a much deeper and comprehensive level of access than the limited interface set that the iphone provides.

But I could be quite, quite wrong!
At this point, I believe anything further from me would come across as suborn and argumentative, plus I don't trust myself to know all the facts either, so for now I'm happy to wait and see what the results are and until then, I can't wait to play with my new toy!

48

Chronos User Discussion / Re: EV Tables?

« on: July 06, 2017, 07:55:16 AM »

At least for basic light levels, this chart looks handy: https://en.wikipedia.org/wiki/File:Exposure_Value_Scale_Visualized_as_Circles.png
Full daylight / outdoor cloudy(some shade) / indoor(normal lights)  is enough steps, but more would be better. It doesn't have to be super detailed and accurate, just a quick lookup table to work out rough numbers so you have some ideas where to start and how things compare. The tables also look predictable so once you have them made up you can guess between the lines.

I know that the same F-stops give the same level, I'm looking for a way to compare, for example, what sort of shutter speed(And thus what frame-rates) I can expect with the  Zenit  300mm f/4.5 lens I've been given compared to, say, the Computar 12.5-75mm f/1.2.

It would be handy to be able to have  rough lookup that lets you go one way or the other. To know where to expect your shutter speed to be what 'x' F-stop and 'y' light level or  'Can I get away with '2x' fstop and a beter depth of field instead. So you know what sort of lens you after.

I was under the impression at the start that anything under abour F2 or 3 was unusable on this camera unless you had some really big arc lamps, this has been proven quite wrong and such a chart would have been handy.  Even if it's just for the range of lenses that are sold with the camera.

49

Chronos User Discussion / EV Tables?

« on: July 06, 2017, 12:04:07 AM »

Because this is a non-standard sensor/application, would it be an idea to start working out exposure/shutterspeed/f-stop tables?   ( https://en.wikipedia.org/wiki/Exposure_value )

I'm very new to 'real' cameras, this is be my first one that isn't a point-and-shoot or a mobile phone so I've been asking around and trying to get an idea of how different factors interact. (I am finding out about the problem with depth on field and low F-stops.  *grumble*)

There seems to be a way to combine  light levels, your lens's f-stop and the sensor to give what shutter-speed(And thus framerates) you can expect/should use.
Or the other way, where given a lighting condition and desired shutter speed, what f-stop lens you would need to give enough light to have this work

I know these are meant to be ball-park figures and your final settings are done on the day, but it would be nice to have at least a basic chart showing roughly what you can do with what lens at what lighting level and to at least give you somewhere to start when playing with the camera.

Or is this all basically irrelevant in this application and it's purely a try different lenses until you find one that you like?

50

Software Dev / Re: GPL Source Code

« on: July 05, 2017, 05:34:36 AM »

The disclaimer is only here so I don't come across as arrogant know-it-all, I'm trying to argue a point, not trying to come across as an asshat. I sometimes fail at making the distinction clear.

This also depends on what you plan to do. If the core camera libs and main app is LGPL, you can write your own app(I hate that word, what was wrong with 'program'/'application', to control the camera what whatever level is provided and if David has provided an API(And hopefully he will!  'libkron' maybe?, interface with the main camera control interface all without releasing any of your code.

As far as I can tell, from the point of LGPL is that the license ends at the API/library boundary. From the license:  "A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License."

So you can write your own programs that do anything from completely take control over the camera to a simple trigger library add-on and keep your code to yourself. The ONLY code you will have to release is any changes made to David or the OS/it's libs/programs, then I believe it would be, at the very least, good manners to release those improvements back for others to enjoy.

How many other cameras have this level of openness? And of those how many are high speed? I don't like the idea of it being open and then someone making improvements to the main software without paying it forward by sharing. Add-ons sure! Separate control programs? Sure! Core improvements? No. If you want to keep your code to yourself, make your own camera, or contact David for a special licence.

Someone who receives this camera after the promotional ones are under no obligation to even mention that they use it and many won't, so I don't consider that a valid argument.
No, I'm trying to argue that this camera would have been much less practical without the GPL and LGPL code running the OS. And while under no obligation, it would be nice if the camera was as open as piratical on top of that so others could build upon that work and give back themselves in the same tradition.

This is why I'm also hoping that when the camera hits end of life in however many years that takes, everything is opened so existing cameras can continue to be improved and worked on. But that is another point entirely.

And... that was way too long and rambling. Sorry, hopefully at least a few points are clear.

51

Software Dev / Re: GPL Source Code

« on: July 04, 2017, 08:06:39 PM »

I should have made myself clear.  I wasn't against allowing MIT licensed code, just keeping the core camera framework/app GPL.
After all, the OS and system libs are already GPLed and there is an argument to be made that this was one factor that made the camera possible. 

https://www.gnu.org/licenses/gpl-faq.en.html#LinkingOverControlledInterface
Adding a clause like that would allow someone to write their own control app and interface it to the rest of the camera and not share it according to the terms of the MIT liciance they are welcome.
HOWEVER if they want to make improvements to the main camera app, should be shared and others should be able to improve apon those changes.  After all, David, and eventually others will put a lot of work into it and I don't like the idea of someone benefiting from his work but not giving back.

Another option might be the LGPL to keep the main app and camera libraries open but allowing proprietary programs to connect and interact.

Again, disclaimer. My opinions only, ultimately it's David's decision as we don't know the final vision for HIS camera/company.

52

Software Dev / Re: GPL Source Code

« on: July 03, 2017, 10:58:09 AM »

I am curious what the future plans are for things like the FPGA code and other deep parts of the camera.
While I'm assuming they won't be released while the camera is in production, will, at end of life, everything needed to make it go be made available?

My own preference would be GPL as much as possible to make any changes to the camera app or other work available back to the community and if you want to do something commercial with it, dual licence it off David. GPL will also not prevent you from writing your own apps for the camera under whatever licence you wish.

However, it's not my camera, these are only my own views and even being as open as it is, is already awesome.

53

Chronos User Discussion / Re: SD Card Speeds

« on: June 29, 2017, 11:54:46 PM »

I intend to do that when I have it in a few weeks. The easy mark in/out feature will make a huge difference, I know.  I just thought making sure the external storage is not the limiting factor is a good idea.
It'll be used in makerspace and other similar environments with many users so write speed may be important.
I'm just gathering up useful parts. This is the first 'real' camera I've owned so the first time I've needed to buy an SD card above 8Gb and there is a /huge/ price difference between a 64Gb 4MB/s and the 95MB/s cards 

54

Chronos User Discussion / SD Card Speeds

« on: June 28, 2017, 08:48:29 AM »

There used to be another thread about SD cards I can't find.. Please move this comment if it's obvious!
What is the maximum rate the camera can write out to a card? Is it worth getting things like the SanDisk Extreme's with their 90MB/s write speeds or will it have no benefit over the cheaper 40MB/s ones?

And what about writing to a USB drive? Any advantage over SD card vs. USB speed wise, or is the limitation the encoder?

55

Chronos User Discussion / Re: Inexpensive neck strap mounting on the Chronos camera

« on: June 28, 2017, 08:32:38 AM »

Just ordered some of the 1/4" mounts from China. They look like they'll be easy to screw in and out if needed.
I suspect that the camera will spend most of it's time on a tripod but having a strap gives a bit of extra security when it's hand-held, plus makes it look more camera like.

These are the mounts I found in a quick search: https://www.aliexpress.com/item/5PCS-Camera-Shoulder-Quick-Sling-Strap-1-4-Screw-Connecting-Adapter-Free-Shipping-Tracking-Number/887107226.html?
Just got a super cheap strap, we'll likely find a better one later.

Do all the 1/4" mounts have helicoil inserts or just the bottom/side one? I know that was going to be a feature, I'm unsure if it made it to the final production.