Derp, never mind. Mistook Hz for 2x freq of light transitions at a given Hz.
Etiquette, expectations, entitlement...
@autoexec_bin | #magiclantern | Discord | Reddit | Server issues
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.
Show posts MenuQuote from: EOSHD on September 07, 2020, 01:48:15 PM
It might be safer to use a fast SD card instead for long 8K and stress test 4K recordings. CFExpress cards do get very hot.
Quote from: names_are_hard on September 07, 2020, 07:04:38 AM
Okay, different than I was imagining but there might still be a way: phone VPNs to some server, and phone bridges VPN network and wifi network. Cam connects to phone wifi, server can transparently see all packets from the phone because the networks are bridged. No NAT required.
The python local solution still seems easier.
Quote from: names_are_hard on September 07, 2020, 06:46:28 AM
Oh, direct USB link to the cam from phone? That's probably what I didn't understand. In that case you could maybe use the phone as a hotspot, it's VPN'd to some network you control, and then the camera talks to phone via wifi through MITM proxy... but this is getting ridiculously complicated.
Quote from: names_are_hard on September 07, 2020, 06:35:44 AM
VPN allows controlling DNS. So, you say blah.com is at 192.168.2.2, *that* is a MITM proxy, it requests the real page from camera.xxx, relays that response back to the client *but removes the CORS info*, and then the client doesn't see any CORS, so it does what you want.
Quote from: names_are_hard on September 07, 2020, 06:12:24 AM
@horshack - I don't know what you mean by a CORS proxy. CORS is a server value that is sent to the client by whatever route. The client can choose to honour CORS policy. Modifying the client means you can ignore the policy, controlling a proxy in the route means you can remove the CORS policy. If you have VPN on a client, and camera connected to some machine also connected to the VPN, then client and camera are on the same network. So I *think* the combination means you can remove the parts that are difficult. But I've never used Canomate so I could easily be misunderstanding something.
Specifically, Wireguard uses TCP-over-UDP. UDP for low latency, TCP for convenience. The two endpoints need a route, they *think* they're talking TCP and are next to each other, but the TCP packets are encapsulated in UDP. At TCP level the client-server looks one hop away, at UDP level it's whatever route your network / ISP / etc has.
Quote from: Lars Steenhoff on September 06, 2020, 10:50:44 PM
Yes for sure, it would be good to know when the camera is really overheating based on the sensor and not on the timer.
Quote from: names_are_hard on September 06, 2020, 11:21:57 PM
@horshack - a VPN will look like the same network, you get an additional network interface, with the phone and vpn endpoint being in the same subnet. Everything is tunneled, so you will see this as one hop, you won't see ISP or phone provider in the middle. Wireguard or OpenVPN are both free and available on most everything. Wireguard is supposed to be easier to configure. You can then configure the VPN to provide DNS, with that DNS server that you control routing whatever names you want to whatever IPs - so you can make the proxy transparent with the only config needed on the phone being the VPN. Of course, you're trusting the VPN an awful lot!
It looks like your Python works and it's probably easier for people to use.
Quote from: names_are_hard on September 06, 2020, 09:03:40 PM
True for iPhone, but extensions are allowed on Android. If you were determined you could also VPN through a MITM proxy to modify the response header to strip CORS, that would work on any phone supporting VPN. I suspect not a very practical solution for the intended audience
Quote from: names_are_hard on September 06, 2020, 08:44:04 PM
CORS is a client side check. You can disable / fake it with a browser plugin, or a proxy.
https://chrome.google.com/webstore/detail/allow-cors-access-control/lhobafahddgcelffkeicbaginigeejlf?hl=en
Not a great suggestion long-term as it will decrease your security if you forget and leave it active. Might work for testing.
PrintCameraInfo
SyncDateTime skewsecs=86400
PrintMessageToLog message="Pull battery NOW, wait a few seconds, put battery back in, wait 10 seconds, then press <ENTER>"
WaitForEnterKeyToContinue beep=1
SyncDateTime
canomate v0.02 - Automation Utility for Canon cameras (uses Canon Control API via WiFi)
Copyright (c) Horshack, System Time: 09/06/20 10:43:13, Py: 3.8.0, OS: Windows
PrintCameraInfo: Model: Canon EOS RP, S/N: XXXXXXXXXXXX, Firmware: 1.5.0
SyncDateTime: Changed camera time from "Sun, 06 Sep 2020 10:43:13 -0800 DST" to "Mon, 07 Sep 2020 10:43:13 -0800 DST"
PrintMessageToLog: Pull battery NOW, wait a few seconds, put battery back in, wait 10 seconds, then press <ENTER>
WaitForEnterKeyToContinue: Press <Enter> to continue...
SyncDateTime: Changed camera time from "Mon, 07 Sep 2020 10:43:15 -0800 DST" to "Sun, 06 Sep 2020 10:43:16 -0800 DST"
>>>> canomate session over (exit=0), logs at "C:\develop\canomate\canomate-appdata"
Quote from: a1ex on September 06, 2020, 03:26:24 PM
Cool hack - it's the clearest proof the "overheating" is timer-based, if you ask me.
Well, this particular hack is easy enough to automate - I wouldn't be surprised if somebody comes up with a one-click version within the next few days or weeks (also mentioned on Twitter). Motivation is high in the R5/R6 user community - much higher than for porting ML on 5D4, EOS R and the like, in my opinion. So, while it's definitely a low-hanging fruit with high rewards, I don't see anyone paying for a slightly more polished version of this hack. A free one will very likely appear sooner or later, without our involvement.
BTW - I feel a lot safer knowing this hack was discovered by third parties - even if it was documented on our forum. There's no single person behind it - all of the previous iterations paved the way to this version of the hack ("standing on the shoulders of giants"), and I'm pretty sure it will be further refined by the community.
Now, back to my (covid-related) research
Quote from: sarangiman on July 18, 2013, 11:19:38 PM
But typical 'engineering' DR calculations using SNR of 1 as the lowest signal don't consider shot noise, correct? Therefore, one could still say that the engineering DR is extended to FWC/read noise @ISO 1600, which is ~14EV. If you're using a lower SNR cutoff of, say, 20, then the DR is much more modest (considering the increase in shot noise contributions you mention).
Quote from: sarangiman on July 17, 2013, 10:45:50 PM
Hi horshack-- why would you 'reduce photons collected by half'? The exposure at the sensor plane is not changed; there is only one exposure. The ML hack is simply changing what you do with that exposure data, & so should not affect the SNR save for actually increasing it in shadows by reducing the effects of downstream noise (after ISO amplifier) in the ISO 1600 exposure.
The focal plane exposure (in terms of shutter speed/aperture) remains the same for both ISO 100 & ISO 1600 exposures; it's not like two separate exposure are being made (where the ISO 1600 exposure would have 4 stops less exposure which, yes, would increase the effects of shot noise).
Let me know if I'm misunderstanding you.
Quote from: a1ex on July 17, 2013, 07:04:20 PM
@horshack,
I don't know who theSuede is (he seems to know some stuff though), but please ask him to read the PDF. I'm pretty sure he didn't.
In deep shadows I only use data from the higher ISO, therefore his averaging formula does not apply here.
Quote from: pulsar124 on April 21, 2013, 07:41:52 PM
I have another suggestion for dot-tune improvement. How about an optional 'cumulative' mode? Specifically, when testing zoom lenses or/and lenses at different distances from the target, one often gets different good dot-tune intervals for MA. E.g, my Sigma 17-50 has MA say -15...-2 at 17mm, and -5...+5 at 50mm. The current dot-tune implementation is not very useful for finding a single compromise value for MA which would be acceptable at any FL. All I get is either one FL or the other FL values; the important interval width information is discarded. But if ML had a cumulative mode, and let me run dot-tune a few times at different FL, and then computed a single compromise value taking into account interval widths, that would be very helpful. In my example, the common MA interval for both FL is -5...-2; the compromise value would be either -4 or -3. At the very least, you could make ML print out the intreval at the end of every calibration; the compromise value would be computed manually.
Quote from: msowsun on March 24, 2013, 11:56:35 PM
I have a 5D Mk II running v2.3.NEXT.2013Mar19
While running Dot Tune AFMA with 200mm or longer lenses I would sometimes get a bug: Each and every MA box would light up green during the test on all 4 passes. (even with -100..+100 selected). This would result in a new AFMA of "0" and an Error message "Double-check the focus target". This would happen a few times in a row. Changing Focus Targets, distance, and lighting, had no effect. I would then exit the program, reboot the camera, and try various other things until it went away. This only happened a few times and I am not even sure how I was able to correct it.
Any thoughts on what was going on?
Quote from: pulsar124 on March 04, 2013, 06:28:31 PMI've considered that, exposing the low-level algorithm parameters to the user in the menu. It would be up to Alex. There would actually be three parameters:
Thanks for the detailed response! But this begs a suggestion - would it be possible to let the user choose both the number of passes and the duration of one measurement, from the ML menu?
Quote from: pulsar124 on March 04, 2013, 05:57:23 PM
I just did fairly comprehensive testing of dot-tune/ML on my 50D, using magiclantern-v2.3.NEXT.2013Mar02.60D.550D.600D.50D.500D.5D2.1100D.zip. The results are reported here:
http://photography-on-the.net/forum/showthread.php?t=1280584
In particular,
Quote from: 1% on March 04, 2013, 04:05:29 PMNot sure, but I would think yes (for zooms).
But is "all lenses" scaled across focal length too? Lots of little quirks it seems.
Page created in 0.108 seconds with 13 queries.