Canon 6D N

[Busted Knuckles]

I have never missed GPS or wifi on any of my bodies, so that would not be a sacrifice for me. 30% price cut on that and another 20% to skip video ... :

I find it a bit strange that they sell both versions here in Norway tough. I don´t believe many are willing to pay the price for GPS and wifi.

Good thing about the 6D is that you can use your 'S' screen in it. It's actually a very fine camera, although I think
you may find the controls a tad soft compared with the 5DIII/1Dx.

Of course if you get bored with it you can always give it to your wife as a new body

Now there's a conversation that could go bad from the outset - 'Hey honey, I have a new body for you...' ;D

He he, that´s the second time in a couple of days where that "body" thing deviates peoples minds

Especially if she was expecting a little M body.... OH, you mean that kind of body! I am slow to deviate from my OCD

 

[Mt Spokane Photography]

I don't know how good Wi-Fi is on a 6D, and I don't use a smart phone. I thought that the Wi-Fi on the G1X I bought would be great for transferring images directly to my home internet NAS, but I have to have a Canon utility running on the computer to get a transfer, and that doesn't work for me.


So, the Wi-Fi was a bust. I'm glad to hear that GPS works as well as it does. Is Wi-Fi on the 6D as bad as on the G1X??

 

[Marsu42]

Is Wi-Fi on the 6D as bad as on the G1X??

Once you manage to get around the braindead Canon limitation (you must install a virtual wifi access point on your pc to connect the camera) it's quite ok.

The limitation is that obviously without a real antenna the connection strength is limited when a wall or a long distance is involved, and even @100% speed I'd rather put the sd card into my laptop than to wait for the wifi transfer.

However " gift horse and such" ... and I recon it's invaluable once you use it for certain wildlife setups or quick blog uploads for journalism. For longer runtime, an external power source or grip is advisable though to extend the battery time.

 

[dgatwood]

I don't know how good Wi-Fi is on a 6D, and I don't use a smart phone. I thought that the Wi-Fi on the G1X I bought would be great for transferring images directly to my home internet NAS, but I have to have a Canon utility running on the computer to get a transfer, and that doesn't work for me.


So, the Wi-Fi was a bust. I'm glad to hear that GPS works as well as it does. Is Wi-Fi on the 6D as bad as on the G1X??

Not sure how bad the G1X was, but on the 6D, it is still pretty badly designed, IMO. The core problem is that their CPU is puny, and they're running their own half-assed embedded operating system instead of something with actual networking capabilities.

The first thing that I'd do if I were designing the next camera would be to use DRYOS solely for the guts of the camera operation (if at all). There's really little need for a RTOS in a still camera, except as a hack to try to work within the limits of a hopelessly inadequate CPU. The problem is, the farther you go down that path, the more exponential the effort becomes to add what would be trivial features on a normal operating system with a non-underpowered CPU.

Instead, I'd drive the UI with a modern ARM CPU (probably dual-core) running an embedded Linux OS. That would get you much better, much more robust Wi-Fi support, plus network filesystem support, faster network communication without bogging down the UI hopelessly, and lots of flexibility for future expansion. The camera could be a Bonjour-advertised web service, with the ability to download complete photos in addition to the camera-scaled versions (that limitation is *really* annoying on iOS).

I'd also store cached thumbnails of each photo in flash, nuking them when the flash card starts to get full, which would dramatically improving performance when skimming through photos on your phone. I'd use a SQLite database to store the thumbnails, yielding fast access without going through the relatively slow filesystem.

And so on.

 

[Marsu42]

The first thing that I'd do if I were designing the next camera would be to use DRYOS solely for the guts of the camera operation (if at all).

Oh no, I hope they keep using dryos, after all this is what makes Magic Lantern run ... even with a oss os, they most likely would have to scratch a lot of their work. From a ML programer's perspective, dryos seems to be pretty ok esp. considering Canon developed it on their own to avoid license fees. Of course with the catch that Canon doesn't release an sdk and you have to find and figure out all functions for yourself, but that's not the os' fault.

As for needing a rtos or not, I cannot quite say (though I guess the ML devs could) - but I figure there is a good reason they use it other than some workarounds. Linux has a considerable overhead and for running on embedded you have to customize it all the time (see Android or routers running Linux). And you really don't need Linux on your EOS, you can already play Sokoban and Arkanoid with Magic Lantern :->

 

[dgatwood]

As for needing a rtos or not, I cannot quite say (though I guess the ML devs could) - but I figure there is a good reason they use it other than some workarounds. Linux has a considerable overhead and for running on embedded you have to customize it all the time (see Android or routers running Linux). And you really don't need Linux on your EOS, you can already play Sokoban and Arkanoid with Magic Lantern :->

You get a lot of functionality for that extra meg or two of RAM. There's a reason no cell phone company has been successful by writing a mobile OS from scratch since... well, Palm, give or take. Proper networking is quite complex to get right, particularly if you care about performance. It's moderately hard even at the application level. It's a b**** and a half at the kernel level. Even Apple repurposed and scaled down an existing OS (OS X, derived from 4.3/4.4BSD) for their phones and other hardware. A company trying to do it themselves is pretty insane.

 

[Marsu42]

A company trying to do it themselves is pretty insane.

Correct me if I'm wrong - but I guess Canon is licensing some ip core with sdk and then either puts it inside one of their custom chips or adds another chip on its own (probably together with gps). If that's so, then Canon dryos doesn't do anything different than Linux would do: interface with the wifi ip core and do some high level requests like "please connect to xyz" or "transfer image abc"?

 

[dgatwood]

A company trying to do it themselves is pretty insane.

Correct me if I'm wrong - but I guess Canon is licensing some ip core with sdk and then either puts it inside one of their custom chips or adds another chip on its own (probably together with gps). If that's so, then Canon dryos doesn't do anything different than Linux would do: interface with the wifi ip core and do some high level requests like "please connect to xyz" or "transfer image abc"?

I suspect you're correct about how they do things currently, which could explain why it is so broken. The more sane approach would be to use a bog-standard standard Wi-Fi chipset hanging directly off the bus of your choice on some bog-standard ARM code. Better yet, use an ARM SoC that contains a Wi-Fi chipset built-in. Either way, Linux would be providing the networking stack, which would probably be a lot more spec-compliant than most of these embedded TCP stacks, and would provide a full set of networking APIs, with full service discovery, and most importantly, proper multitasking.

If they used a proper multitasking OS, you wouldn't have to tell the camera in advance whether you planned to use a phone or a computer to connect to it. You wouldn't have to choose between Wi-Fi support and video recording capability (though during recording, the camera software might still need to limit the speed at which it reads photos or video from the card to send over Wi-Fi if the flash card isn't fast enough to handle both operations at once, or possibly refuse all non-streaming connections while recording is in progress). And so on.

At least from the outside, it looks like the Wi-Fi implementation is badly hampered by a poorly chosen architecture that really isn't suited to networking. I mean, it isn't surprising from a company that has always historically used RTOSes, but the RTOS approach really doesn't scale very well as the technology becomes more complex. That's why, for example, when Apple moved from iPods that played music to more complex devices that supported networking (iPhone and iPod touch), they ditched the RTOS for a full-blown OS. That's why nearly every TV and set-top box out there runs some version of Linux. That's why nearly every phone out there runs either iOS (based on BSD) or Android (based on Linux). That's why nearly every Blu-Ray player runs some version of Linux. That's why nearly every home DSL or cable router runs some version of Linux or BSD. And so on.

Then again, I've worked both at Apple and at an embedded Linux startup, so it's possible that I'm just a bit biased against RTOSes.

 

[sagittariansrock]

The first thing that I'd do if I were designing the next camera would be to use DRYOS solely for the guts of the camera operation (if at all).

Oh no, I hope they keep using dryos, after all this is what makes Magic Lantern run ... even with a oss os, they most likely would have to scratch a lot of their work. From a ML programer's perspective, dryos seems to be pretty ok esp. considering Canon developed it on their own to avoid license fees. Of course with the catch that Canon doesn't release an sdk and you have to find and figure out all functions for yourself, but that's not the os' fault.

As for needing a rtos or not, I cannot quite say (though I guess the ML devs could) - but I figure there is a good reason they use it other than some workarounds. Linux has a considerable overhead and for running on embedded you have to customize it all the time (see Android or routers running Linux). And you really don't need Linux on your EOS, you can already play Sokoban and Arkanoid with Magic Lantern :->

Can't you guys at Magic Lantern transform this barebones Wifi to something 'magical'? (I speak without any programming knowledge, of course. So, sorry if this is a dumb question)

 

[Marsu42]

Then again, I've worked both at Apple and at an embedded Linux startup, so it's possible that I'm just a bit biased against RTOSes.

Interesting observations, though I (I never did rtos programing) like to add this theory: It's easier to debug and build a reliably system because if it works once then it'll work every time sine timing is fixed and this no problem. Do Nikon and/or Sony and other companies use multitasking non-rtos designs in their cameras?

Btw I don't find the Canon wifi implementation *that* horrible, video/wifi is bothersome but I don't do this, my main issue is that you cannot connect to a laptop in client mode but have to setup a virtual ap on the computer.

 

[fotonunta]

This is a great deal... if could get to return back in time i wolud buy Canon 6D without gps or wifi - i dont use them ever.

 

[dgatwood]

Then again, I've worked both at Apple and at an embedded Linux startup, so it's possible that I'm just a bit biased against RTOSes.

Interesting observations, though I (I never did rtos programing) like to add this theory: It's easier to debug and build a reliably system because if it works once then it'll work every time sine timing is fixed and this no problem. Do Nikon and/or Sony and other companies use multitasking non-rtos designs in their cameras?

Except that modern RTOSes don't really work that way unless you're dealing with microcontrollers. If I understand correctly, modern RTOSes are usually a bizarre kludge of multitasking and non-multitasking parts, enforcing partial real-time behavior through scheduling. The bigger difference between a modern RTOS and Linux is that the RTOS likely has a much smaller kernel footprint, but as a result, has a lot less functionality.