"Be the filmmaker" they say
https://www.canon-europe.com/cameras/eos-r5/
EOS R5 mirrorless 5D?
https://global.canon/en/news/2020/20200213.html
Resolution, IBIS, and Dual Pixel Auto focus means nothing. If it can't do internal RAW at least 10bit then the 5D2 is better that crap.
Quote from: yourboylloyd on February 15, 2020, 04:06:49 AM
Resolution, IBIS, and Dual Pixel Auto focus means nothing. If it can't do internal RAW at least 10bit then the 5D2 is better that crap.
:D :P
Aside from technical improvements, I'll be switching for sure in future (unless they screw something really bad). Missing thumb wheel was hard for me to live with, even if I got used to after a year ;)
I just fear the pricing, as if those are not just marketing words, I believe it will be more expensive that R was.
This camera is looking really promising (of course if Canon won't decide to cut rumored functionality).
I won't be a first runner buyer but will definitely save $ to switch from my 5d3 (eye following DPAF and video modes are so lacking in my 5d3 cam..).
(https://www.canonrumors.com/wp-content/uploads/2020/03/12.jpg)
(https://www.canonrumors.com/wp-content/uploads/2020/03/02.jpg)
(https://www.canonrumors.com/wp-content/uploads/2020/03/11.jpg)
(https://www.canonrumors.com/wp-content/uploads/2020/03/10.jpg)
Quote from: Dmytro_ua on March 04, 2020, 06:03:51 PM
(eye following DPAF and video modes are so lacking in my 5d3 cam..).
The real reason the 5d2 is better than the 5d3 is because the ZOOM button is on the right side. I have no clue why the 5D3 has the zoom button on the left. That's at least one thing this camera has going for it is the correct ZOOM button placement.
But who knows if it will even matter. DPAutoFocus is apparently so amazing you don't ever need to verify your shots anyway.
Quote from: yourboylloyd on March 05, 2020, 06:14:39 AM
The real reason the 5d2 is better than the 5d3 is because the ZOOM button is on the right side.
It's not an issue at all - check the latest Danne's ML build, it has an amazing fast zoom option in LiveView.
My story is interesting. I bought 5DsR. About a month passed and was horrified. Some kind of imperfection, everything is fuzzy, soap, etc., is sold. I bought 5DMarkIV. I took six months, but still thought what happened to DsR? I purchased 5DsR again. Large files are torture, because I shoot a macro, and there are stacks of frames, and returned to 5DMarkIV again, but only for a week. After a week of testing 5DsR, I apologized,, (https://grilliam.com/) 5DMarkIV passed it to my daughter, and he finally returned to 5DsR and not only returned, but also bought a second 5DsR. 8)
Thanks to me as a beginner, it's very interesting to read all about the Canon R5. I bought it 2 weeks ago and am trying to figure it out.
Quote from: yourboylloyd on March 05, 2020, 06:14:39 AM
The real reason the 5d2 is better than the 5d3 is because the ZOOM button is on the right side. I have no clue why the 5D3 has the zoom button on the left. That's at least one thing this camera has going for it is the correct ZOOM button placement.
YES ARGH!
The 5D3 and 5Ds are so much worse than the 5D2 because of this (probably mark 4 as well). You also have to press the zoom button twice to get any zoom (WTF).
I miss the 5D2, such a great experience.
Quote from: Sportegan on April 12, 2020, 11:33:00 AM
Thanks to me as a beginner, it's very interesting to read all about the Canon R5. I bought it 2 weeks ago and am trying to figure it out.
You were deceived as R5 is not announced yet
I guess our two new colleagues can't see the difference between EOS 5DS R and EOS R5.
https://www.usa.canon.com/internet/portal/us/home/explore/product-showcases/cameras-and-lenses/eos-r5
https://www.canonrumors.com/canon-announces-more-mind-blowing-specs-for-the-canon-eos-r5/
Just one quote:
QuoteInternally recorded and uncropped 8K RAW Recording up to 29.97 fps with Dual Pixel CMOS AF, and HDR-PQ Recording (H.265) capability.
Well, price will hurt for sure.
(https://i.imgur.com/WMKrXDZ.jpg)
10 bit 8k internal NON CROPPED WITH A FLIPPY SCREEN??!?!?!?!?!?!?!?!?!?!?!?!??!?!?!?!? No way.... no freaking way. it doesn't even have 8bit anything....
Sorry guys. This camera is going to pretty much kill ML... unless it's $6,500 body only w/ no batteries, no front cap, no battery cover, no camera strap, no24p, no 25p, and no product box.
Wow... I mean the 120p 4k was good enough to get me. I actually can't believe this. This camera is everything anyone could ever ask for. And look at how small it is!
Yep, this camera has every spec we could ask for right now (except raw, but meh...).
Awesome 8K with Canon Colour Science should be glorious!
Quote from: ZEEK on April 21, 2020, 01:26:39 AM
Yep, this camera has every spec we could ask for right now (except raw, but meh...).
Awesome 8K with Canon Colour Science should be glorious!
except RAW? What were you reading? There is literally an entire tab that says 8K internal RAW Recording
Just saw the above sample :o. JEEPERS!! This camera is even more nuts!
Quote from: yourboylloyd on April 20, 2020, 10:38:40 PM
This camera is going to pretty much kill ML...
I don't think so. If you have to sell your kidney to buy the body and a few lenses for it, especially after the coronavirus crisis, ... I don't think that too many people from the ML community will be able to afford it.
Like others I've been reading about the announcement from Canon and, of course, it's going to be an incredible camera, especially for professionals.
But, and I think these and big buts, it will be expensive for mere mortals, like myself, and, critically, it will not have one ML killer feature, namely in-camera Lua scripting.
I must say, that extending the scripting API remains an area of ML that could continue to take ML to 'better' things.
Sadly I remain a non-developer.
Cheers and stay safe
Garry
I fully agree with you, Garry. The creativity that ML offers and will also offer with our old cameras for free in the future is unbeatable by any camera on the market!
I just got reminded about CF-to-SATA thread (https://www.magiclantern.fm/forum/index.php?topic=5470.msg177330#msg177330). And I was going to post here that finally we will be able to attach HDDSSD to our cameras, as there are CFast to SATA adapters (CFast is in mostly a fancy connector for SATA).
And then I checked again and it's CFexpress :o Didn't even notice that there's a new standard already. PCIe v3 x4 / NVME - I wonder if someone will make m.2 NVME -> CFexpress adapter ;)
They are a couple of CFexpress -> (m.2 | pcie) adapters, and while I can't find any photo of "the other side" of pcbs, all PCIe traces seems to run directly between connectors.
Quote from: kitor on May 02, 2020, 10:00:43 AM
I just got reminded about CF-to-SATA thread (https://www.magiclantern.fm/forum/index.php?topic=5470.msg177330#msg177330). And I was going to post here that finally we will be able to attach HDDSSD to our cameras, as there are CFast to SATA adapters (CFast is in mostly a fancy connector for SATA).
And then I checked again and it's CFexpress :o Didn't even notice that there's a new standard already. PCIe v3 x4 / NVME - I wonder if someone will make m.2 NVME -> CFexpress adapter ;)
They are a couple of CFexpress -> (m.2 | pcie) adapters, and while I can't find any photo of "the other side" of pcbs, all PCIe traces seems to run directly between connectors.
Hold on, ATA133 which is the last version of IDE, only runs at maximum of 133mb/s. Attach to a SSD or HDD seems just save money for the captaincy?
The exposed socket the external power supply seems more dangerous and unstable xD. But it is a cool idea anyway and did you already tried that out? If not, I am glad to work on it.
The camera focuses quickly, but I can't control it quickly. You need to change the ISO, you need to change the focus point, the finger reaches for the joystick, but it is not there, you need to go to the cross. As a result, I often used the touch screen to indicate the focus point. The handle is so comfortable. I am sure that anyone who buys this camera will get used to it.
I think it's about sata, not ata ... The last standard of sata is sata3 (750 MB/s)
Quote from: yokashin on May 03, 2020, 12:04:44 PM
I think it's about sata, not ata ... The last standard of sata is sata3 (750 MB/s)
Oh yeah lol, I miss understood. However there are many examples doing CFexpress to SATA on YouTube. Shouldn't be a big deal.
Quote from: yokashin on May 03, 2020, 12:04:44 PM
I think it's about sata, not ata ... The last standard of sata is sata3 (750 MB/s)
In case of R5 it's not even SATA (CFast), but Canon skipped directly to PCI Express / NVME (CFexpress).
Quote from: Aperture Science on May 03, 2020, 12:13:54 PM
Oh yeah lol, I miss understood. However there are many examples doing CFexpress to SATA on YouTube. Shouldn't be a big deal.
Are you sure?
CFast to SATA do exists, as CFast uses SATA protocol. But
CFexpress is NVME (PCI Express), that's why I wonder if there will be similar trick possible.
But even if possible - probably a little harder due to PCIe signalling requirements.
By the way - there are three types of CFexpress cards - A, B, C. They differ in physical dimensions and number of PCIe lines. I can't find any information which one will be supported here, but I bet for type A, which is physically similar to SD card.
Most likely type b since Canon is using it on c500ll
This camera can potentially kill C300 and C500.
i wish that was true but no canon just announced a new c300 mark3 https://www.canonrumors.com/canon-officially-announces-the-cinema-eos-c300-mark-iii/
they are to clever about the way they market cameras and cine cameras i have been dealing with them since 1980s they want you to buy all the models.. crippling features is canon's speciality
Quote from: kitor on May 04, 2020, 08:10:46 AM
In case of R5 it's not even SATA (CFast), but Canon skipped directly to PCI Express / NVME (CFexpress).
Are you sure? CFast to SATA do exists, as CFast uses SATA protocol. But CFexpress is NVME (PCI Express), that's why I wonder if there will be similar trick possible.
But even if possible - probably a little harder due to PCIe signalling requirements.
By the way - there are three types of CFexpress cards - A, B, C. They differ in physical dimensions and number of PCIe lines. I can't find any information which one will be supported here, but I bet for type A, which is physically similar to SD card.
Of course SATA line do not contain the pcie lolololol, I was just saying there are things like that by change pcie into SATA ;)
There's some interesting discoveries on the R5 to suggest that the overheating is actually a software limitation imposed by Canon. I wonder what it would take to develop ML to remove them.
https://www.eoshd.com/news/eoshd-testing-finds-canon-eos-r5-overheating-to-be-fake-with-artificial-timers-deployed-to-lock-out-video-mode/
Yes, thought about creating a topic about this, too.
This could be a great opportunity to make paid ML development work. In my opinion it looks like there are some people willing to donate some amount to disable/bypass artificial software limitations for R5.
On the other hand: Terrible timing. Covid-19 and whole industries in a turmoil.
Really don't know if this could be a way to obtain sustainable cash-flow for upcoming ports.
Another one: I think there might be a niché market for a company modifying R5 with some kind of cooling system. Which could do great for Canon users looking for reliability but would be rather useless if they are unable to bypass said artificial software limitations.
But this is a hen-egg-issue.
Tilta actually announced a cooling system for the R5 already, but the problem is that if the overheating is software based timers it will have no effect. https://tilta.com/2020/07/tiltaing-camera-cage-for-canon-r5/
EOSHD findings do correlate with many reviewers saying that the ambient temperature made no difference to the recording and cooldown times. That they were exactly the same in both hot and cool environments, and removing the battery and even adding ice etc had no effect. I think I even heard that it overheated in Antarctia or somewhere really cold, so the software based timers would actually explain this behavior.
This could be a software limit and still not be artificial market separation, but instead a lazy way to pass certification. For consumer electronic devices, they're not allowed to get too hot to touch (defined as something like external temp of 45 or 50C I think, don't recall all the details).
If you want your camera to work in UAE and Alaska, the lazy way is measure it at highest load in the worst conditions, then put a timer in so it passes certification. That way you don't need fancy temperature sensors in the cam, or conditional code to check and perform different actions in different conditions. Timers are simple and reliable.
About EOSHD findings: who knows, the value of which temperature sensor is reported by Canon API? Maybe average?
If it's software limit it probably can be resetted by resetting all camera settings. However, timer values can be stored in battery-backed memory (RTC) and not affected by a reset.
There's already another post from EOSHD:
https://www.eoshd.com/news/canon-eos-r5-overheated-in-my-fridge-after-just-60-jpegs-4-c-ambient/
This is getting even more interesting.
As I said: IMO this would be *the* opportunity to make transition to pay-for-ML-feature-development work. Alas: Timing is just off the charts.
Nice testing. That info makes it sound much more like something that can be patched in software, whatever their reason for putting it in.
Canon took 12 months to enable 24p into the EOS RP. They won't care to fix this in any kind of rush. They just don't care about us.
I wasn't saying Canon would be the ones fixing it in software :) ML is software.
Looks like if you take out the backup battery the overheating timer resets and you have full record time :o
Info from what source?
Quote from: Danne on August 21, 2020, 08:42:59 AM
Info from what source?
https://www.eoshd.com/8k/removing-internal-battery-resets-eos-r5-overheat-timer-are-canons-pants-now-completely-down/
Begins to look like one of the sloppiest thermal management implementations ever.
there is aa hardware button to reset the timer. Hope we can do something with the software ! And add a thermal pad to get seomething a bit more reliable. I would love so switch to Panasonic, s5 for exemple but they have DFD autofocus. Someone is working on a TOF module, but I think a software timer reset could be more simple =)
Oh wow. I really want to know how Canon people thought this will slip. With all the marketing that R5 received.
Thankfully this time I didn't preorder >:( You know, IBIS, wheel is back, but I'll stay with first R till the prices drop a bit.
This is actually exciting news! I was worried that the camera actually gets too hot. But believe this, I'm going to figure out a way to uncripple my R6 whenever it comes in. If I have to make a battery hack or if I have to learn C for the next couple of weeks I will do it!
I've never been more fired up in my life.
With hacking R and up, remember that they changed firmware encryption.
I was running stuff on mine, but had to enable bootflag via serial console first.
I'm wondering how hard it could be to run a very simple hack as magic lantern with only one simple task: Reset the overheating counter?
It seem they are writing it into eeprom as it kept from reset even without battery. Only removing the RTC coin cell reset it for now.
Little update at EOSHD with a little help from a1ex and Horshack:
https://www.eoshd.com/news/canon-eos-r5-so-called-overheat-timer-defeated-by-a-single-screw-in-battery-door/#more-24156
EDIT: Thoughts (better not be discussed at EOSHD for obvious reasons) on
QuoteThe 14 minutes and 30 seconds of footage seemed to have vanished from the previous card and was not visible in playback mode when I reinserted that card. It is possible that the abrupt power cut had corrupted the clip.
1) It's logical file won't show up. Hasn't been closed properly by Canon.
Q: Shouldn't it be possible to manipulate the file by adding proper bits and bytes?
Yes, I know: This is not a proper procedure and there is a chance card gets corrupted if battery is pulled during write operations. Still interested if it might be possible. May be useful for critical footage rescue operations in the future.
2) That's one every R5 owner *can* try at home without the battery pull part ...
Does EOS R5 support FAT32 as file system for high-res recording? If so: This would generate chunks that have to be visible. Only last recording leg (up to 4 GB) should be invisible and lost (at least for the moment. See item above ...).
And yes, chance of card corruption exists, too!
Quote from: Walter Schulz on August 23, 2020, 07:45:50 AM
Little update at EOSHD with a little help from a1ex and Horshack:
https://www.eoshd.com/news/canon-eos-r5-so-called-overheat-timer-defeated-by-a-single-screw-in-battery-door/#more-24156
LOL, I only pointed Andrew to this link (Horshack's post): https://www.dpreview.com/forums/thread/4513421#forum-post-64281948
Quote from: horshack
Many cameras don't update the values in NVRAM until they're orderly shutdown, ie when the power-switch is turned to off. They keep the values shadowed in SDRAM until then. This is done both for performance and to reduce wear on the NVRAM. You can see evidence of this on Nikon cameras by abruptly pulling the battery and then plugging it back in - any config/exposure changes from the previous session will be lost.
Canon is a little more clever - they have a latch sensor on their battery doors that performs an orderly shutdown whenever the battery door is opened. This prevents an abrupt shutdown. To work around this someone could tape/jig the door sensor so that it's always pushed-in. The experiment would be as follows:
1. Find a way to hold the battery door latch sensor in
2. Power on the camera with the battery door open
3. Record video to the point of thermal cutoff (but not power-off shutdown)
4. Pull the battery
5. Reinsert the battery
6. See what the available video time is
There's a chance Canon periodically updates the NVRAM during the session (or when video recording stops), esp for something as important as thermal management. In that case it may be necessary to pull the battery while the video is actively recording. This may leave the CF/SD card in an indeterminate state so it may require a format when the battery is reinserted.
There are also others who tried this trick in various ways (e.g. in this slightly NSFW clip (https://www.youtube.com/watch?v=ygO64oE5VI0), or this variation with a battery grip (https://www.youtube.com/watch?v=b-qeqNY2Nog)), so credits don't belong to me - I didn't discover anything :D
From what I've seen, the trick works if one removes the battery in the middle of recording, but no longer works if the battery is removed after properly stopping the video. As Canon firmware is pretty much event-based, they probably configure an alarm timer directly on the RTC chip, as soon as video recording is stopped. That could also explain why the camera "forgets" about overheating after removing the clock battery.
A software patch might be relatively easy if one knows where to look, assuming the internals are similar to M50, EOS R and other DIGIC 8 models (I haven't seen the firmware).
However, before attempting to disable these timers, I should get some updated legal advice. If we were to implement this feature, it could raise some eyebrows at Canon :)
Does the R5 support Canon Basic?
Quote from: a1ex on August 23, 2020, 09:37:52 AMHowever, before attempting to disable these timers, I should get some updated legal advice. If we were to implement this feature, it could raise some eyebrows at Canon :)
Looks like you got legal advice in spring 2019... ;)
Last time I did was in 2014.
Quote from: a1ex on August 23, 2020, 05:46:17 PM
Last time I did was in 2014.
Please do, there are a lot of people including me who would pay for the hack. I will save a lot money from not buying the same camera internals in 6 months for double the "cinema" price.
Quote from: c_joerg on August 23, 2020, 01:27:19 PM
Does the R5 support Canon Basic?
It's not hard to try if you have access to one. Prepare a script card (confirm that it's working on one of your cameras), copy the script from this post (https://www.magiclantern.fm/forum/index.php?topic=23296.msg227190#msg227190) put it in camera and try starting it. If it writes something on card or crashes, then the answer is yes.
But I doubt that it's the case.
new videos about the topic of timers on the r5
Andrew did a timer test, promising results
https://youtu.be/lNtQZW0vX1A
https://www.youtube.com/watch?v=iIFxdG-kjoo
https://www.youtube.com/watch?v=a0HcA_h5aHM
That Sigma FP almost had it, thought r5 had it. But looks like good internal raw stays with 5d3 for now ;)
Sigma fp has good internal raw, I have one and its great. and if you add the ssd you have very nice 12 bit external 4k
Firmware 1.1 for the R5 is now available to download.
https://www.canon.com.au/support/sims-content?pid=f0fe77137eb5430daf673363565cec37&cid=7A8E003792624BB7A511CBCD523C53F5&ctype=fa
:P
"7. Temperature detection and shooting time control in video shooting have been improved. In addition, the total shooting time when the short-time recording and power-on/off are performed repeatedly at room temperature is improved."
So, patching these timers is no longer needed? :P
Quick look at the R5 firmware update - apparently the same file format as on EOS R, but different encryption key. That means, I cannot look inside.
If our enhancements are still needed, it might be possible to enable the bootflag via UART (https://www.magiclantern.fm/forum/index.php?topic=22770.msg211964#msg211964) (which requires access to a physical camera, and some familiarity with digital electronics). Assuming Canon didn't disable the UART port, of course.
According to Gordon Laing https://www.youtube.com/watch?v=3bOeoYI6EYs there are actual some enhancements.
And HDMI streaming/recording without thermal management is gone for good. Declared to be a bug and fixed.
Quote from: Walter Schulz on August 27, 2020, 09:36:45 AM
According to Gordon Laing there are actual some enhancements.
And HDMI streaming/recording without thermal management is gone for good. Declared to be a bug and fixed.
I can´t confirm this, I could record external in 4K HQ up to 3 1/2h untill the SSD was full, with cards in.
So all external recording modes are absolutely usable.
The CFexpress card seems to produce most of the heat, when recording to SD card I got longer 8K IPB and 4K HQ times.
Looking at some exif data, the camera shuts down consistently at 60°C +/- 1
External cooling improves the recording significantly!
-EDIT-
Lets see if the Tilta fan will actuality improve things now with the new firmware
https://tilta.com/2020/07/tiltaing-camera-cage-for-canon-r5/
And the best news of today is that there is a firmware update we can look at :)
Quote from: Lars Steenhoff on August 27, 2020, 12:27:38 PM
And the best news of today is that there is a firmware update we can look at :)
And the bad: No easy way back because you just cannot downgrade to a previous version.
Keep that in mind!
Just wondering about what Walter says...the original firmware of the R5, say the version that's on the first batch out in the wild.
It's nowhere available for download I guess, since it's the original first version of the firmware.
So that means, if everybody does the update to the newer version, there might be a chance that nobody will ever find out how the 'temperature video locking' was controlled originally.
So maybe we never will know if Canon did the 8k videolocking on purpose and not for temperature or safety of the hardware...
::)
So this whole new firmware update could also be used by Canon to get rid of some nasty evidence :P
Hanson's razor: Never attribute to malice that which is adequately explained by stupidity.
Everything I read about this thingy points to sloppy engineering.
Quote from: Walter Schulz on August 27, 2020, 02:04:36 PM
Everything I read about this thingy points to sloppy engineering.
Indeed, probably the most obvious reason.
But if the first firmware is gone...we will never know for sure.
I think it´s proven already.
Who knows, the new firmware might even control temperature reports or even change temperature physically with the actual firmware to come clean. If measuring temperatures like was done before it could be this could be compared.
Youtube reviews are looking pretty grim. Only slight improvements.
Good news is that my R6 has shipped! So we'll see first hand
If what we think is happening, then Canon is walking on rather thin ice.. There will definitely be someone, who will not update Canon software, donate both cameras (with and without software update) to ML, who will compare what was done to new ones in order to hide information and fool customers. I would highly recommend everyone, who has R5 not to update software, instead look reviews on how much improves video, as well as incorporate battery pull method to extend recording times. Meanwhile, ML will come up with something ;)
You may have insights I'm not aware of.
Otherwise trolling.
Quote from: a1ex on August 27, 2020, 07:53:13 AM
Assuming Canon didn't disable the UART port, of course.
At least the connector looks similar to R & RP:
(https://thumbs2.imagebam.com/c9/7c/2f/876c9f1352504681.jpg) (http://www.imagebam.com/image/876c9f1352504681)
and there is a hole in the case for it:
(https://thumbs2.imagebam.com/6c/63/fa/d4ca971352504673.jpg) (http://www.imagebam.com/image/d4ca971352504673)
This arc is made of rubber?
(https://thumbs2.imagebam.com/d1/77/22/3837c11352504866.jpg) (http://www.imagebam.com/image/3837c11352504866)
Proper connector for UART? Accessible when rubber (if any) is removed?
Q: Are those new things or do they exist in other Canon EOS designs?
The EOS R & RP have no rubber at the arc.
The rubber is there for a (hopeful) reason on the R5.
The R6 does not have the rubber though :( (https://i.ibb.co/RzmdygQ/r6.png) (https://ibb.co/NZPbSFW)
Yes, I'm almost sure it's UART, same connector as R, RP, and similar location hidden in plain sight (under rubber).
QuoteThe EOS R & RP have no rubber at the arc.
Indeed, it's hidden under thumb rubber on R. Similar in RP, just a little higher.
(https://i.imgur.com/Dt8kHcjl.png)
And R pinout: https://www.magiclantern.fm/forum/index.php?topic=7531.msg212071#msg212071
and BL dumper: https://www.magiclantern.fm/forum/index.php?topic=22770.msg212069#msg212069
Unfortunately v1.1 means that 1.0 is probably lost for now, considering how many of those were shipped / people wanting to upgrade.
I keep my R v1.0 backup as a relic 8)
Thanks! I really wonder why they decided to change design to an easily accessible one (which adds costs). I'm guessing they realized it would reduce costs on the long run. Just a guess, really!
For R6, as there's no teardown yet (?), after a little digging I found this highres render/photo:
(https://i.imgur.com/7JtVbVFl.jpg) (https://i.imgur.com/7JtVbVF.jpg)
I don't see anything that recalls our familiar connector, but there's this FPC 8 pin connector on top left of PCB, which look suspicious to me, with all the testpads around.
Judging from external photos, this would be not accessible without taking whole port cover part of camera case off, so I'm skeptical about this one.
You mean this thing?
(https://i.ibb.co/kM2C5FP/1.png) (https://imgbb.com/)
It looks too small to be the same thing from the R5's PCB.
(https://i.ibb.co/28dk3wq/r5-r6-PCB.png) (https://ibb.co/1sTmG3Z)
Take a ruler. They are pretty close (y-scale).
Unfortunately it looks like you're right... Even the pins line up
(https://i.ibb.co/6nnGqVt/2.png) (https://imgbb.com/)
Hopefully it's hidden in plain sight to access like the R and RP.
Quote from: kitor on August 27, 2020, 07:44:16 PM
Unfortunately v1.1 means that 1.0 is probably lost for now, considering how many of those were shipped / people wanting to upgrade.
I keep my R v1.0 backup as a relic 8)
I'm not very familiar with ML yet. But from CHDK I know that you can do a dump of the firmware in the camera. Isn't that possible with ML?
If the camera supports Canon Basic, it should be possible ...
But it doesn't make life that much easier. You cannot install a ROM dump file like a firmware file just by using Canon's menu ...
@yourboylloyd, Walter - yup, I was talking about this exact connector.
We need to wait for any teardown to see if it's actually used, but I highly doubt. If you check any other one, they have black markings on pcb, showing where ribbon goes. This one has none.
Plus connector just below that is recessed in PCB so ribbon can pass freely. This one is so close to edge that it looks intentional for easy external access.
A detailed pic showing an opened HDMI/USB latch should give a hint.
I agree: It doesn't make sense to build it like this without an "easy way out".
No hints from what I can see on R6. Unless the screws right there are suspicious. (not to scale, slightly photoshopped to show both rubber ports open).
(https://i.ibb.co/p3PtkD9/4.png) (https://ibb.co/LCPLsw2)
Edit: The R5 and R6 screws on the right do look a little different though
Yes, nothing to be found there. USB- and HDMI-connectors are soldered onto the other side, our UART (or else) should be located slighty to the right (vertically in line with screw?) and well above the top-right screw.
If this trail is correct, it would mean that you need to dismount whole part of case assembly. Looks like 4 screws, unless port cover and entire camera back is one assembly (hopefully not)
What I can tell you is that with patience it was possible to disassemble R to motherboard, without leaving any visible marks ;)
Aligned R6 connector and PCB photo based on assumption silver pads on PCB are for USB-C and micro HDMI respectively (sorry for low res). Then FFC/FPC connector is evidently hidden above screw if not used for something else.
I am definitelly up for ML developement for R5/R6 without doubts.
(https://i.ibb.co/FnjJ7WC/r6-connecors.jpg) (https://imgbb.com/)
So I just got the R6, but unfortunately I noticed that this:
(https://i.ibb.co/0G4ZZvV/20200831-135813.jpg) (https://ibb.co/BCWjjFK)
It looks like Canon probably had a huge liability with ver 1.0.0 and the overheating thing if they're shipping it WITH 1.1.0.
Sucks. Looks like we'll never have the original firmware. Might as well call this one the original.
But anyways, let's look for that bootflag UART port!!
Quote from: yourboylloyd on August 31, 2020, 11:02:56 PM
But anyways, let's look for that bootflag UART port!!
Have you tried to dump firmware (https://www.magiclantern.fm/forum/index.php?topic=24827.msg230085#msg230085)?
Not yet, will try first thing in the morning! (los angeles time)
There is no ROM dumper for the R6.
I've been getting help from guys on discord. I'm going to try to pop open the side panel (with the hdmi/usb/ port) today and see if I can reach the theorized UART port.
Quote from: yourboylloyd on September 01, 2020, 07:44:48 PM
There is no ROM dumper for the R6.
Ant123 linked to test if Canon Basic works. This could lead into dumping rom without opening case.
If not, and you'll find UART, you'd probably be able to enable bootflag through it (if you're brave enough) and then use portable dumper compiled as autoexec.bin - the way we did this with R, after confirming with serial bootloader dump that there are no surprises (IIRC it was identical to M50)
And if you will succeed in any way, remember not to share the rom dump, as it obviously contains Canon's copyrighted code.
Okay sorry. Didn't know that that was a difference. I'll do that now
Okay so I couldn't get EOScard to work. I kept getting the Drive: 1 ERROR Write Failed message so I decided to skip that step after a while and procedded to open up the camera with the help of the guys on discord.
The camera's screws uses a rare "000 phillips screw" that I had to go out and buy a screwdriver set for. I took apart the 4 screws from the side ports and found that the camera actually is accessible on the side like so:
(https://i.ibb.co/gTbH0Nb/unknown.png) (https://ibb.co/NjgQ05g)
The green is another screw that I had to take out in order to let that part of plastic come off.
Now when I did that, I was given acess to the board. Unfortunately I tried my hardest but I could not get the entire thing to come off. But it did allow me to see inside where the suspected UART port is:
(https://i.ibb.co/LPPdBfp/7054f60c9bc74830892c9098ff8aa6d4.jpg)
(https://i.ibb.co/sQ5cq3R/6e0d641e17594f06b61a9532dfafe1ec-1.jpg)(https://i.ibb.co/QCHnBmg/6e0d641e17594f06b61a9532dfafe1ec-1.png)
So it looks easy to get to. The problem is that the pins are extremely tiny. I'm going to try to measure the distance between them once I get a good battery for my calipers. But it's so small that I probably won't be able to tell if the pitch was between 0.4mm or 0.3mm or something.
Does anyone have advice on a way to probe the pins? I have an arduino uno, usb host shield, FTDI USB UART IC 'FT232RL' adapter that can run at 3.3V or 5V, and all the accessories that come with an arduino (breadboard, wires etc). But I don't know how to make a connector that could probe pins that are that small.
@names_are_hard and @coon suggested these two (http://www.jst-mfg.com/product/detail_e.php?series=638) links (https://www.mouser.com/Wire-Cable/FFC-FPC-Jumper-Cables/_/N-ad930?P=1z0wx36) to try to make a custom connector. But I have little experience in that.
I am going to try out the Jtagulator: http://www.grandideastudio.com/jtagulator/
This device can scan up to 24 pins simultaneously and figures out the pinout of UART or JTAG. You can also set the voltage via software at which the device scans the pins (pretty handy for 1.8V pins).
It is a bit expensive but it is also open source so I will solder it by myself within the next few days.
I will let you let you know once I've tried that out but first the PCB and the parts needs to arrive...
Quote from: yourboylloyd on September 01, 2020, 11:49:20 PM
Okay so I couldn't get EOScard to work. I kept getting the Drive: 1 ERROR Write Failed message so I decided to skip that step after a while and procedded to open up the camera with the help of the guys on discord.
Good job! But I suggest you to try again with EOScard. Maybe there need to run it as administrator?
I've tried that. I tried FAT16 and FAT32. I even tried running Windows in safe mode. It just won't work. Someone on discord suggested that I should use a smaller card, or that I should somehow trick my CPU into thinking that my card is smaller.
I'm using a 128gb lexar card. I don't have anything smaller nor do I know how to make my card "look smaller."
I don't know how to use Linux, but I do have a Ubuntu VM. I can possibly try to make the card work if I can do it in Linux. I would need a LOT of guidance though.
Canon Basic has a very, very small chance to work on EOS R. I don't think there are any EOS cams that Canon Basic is known to work on. UART is the most likely route to dump an R rom.
I'm not sure @names_are_hard. A1ex JUST posted this.
Quote from: a1ex on September 02, 2020, 07:04:35 AM
Confirmed working on M50. Very cool!
I have to figure out how to make this work.
Yeah, today I woke up earlier than usual for some reason, so I've dusted off the M50 and tested the dumper :)
Guess what: the EOS R has some Canon Basic scripts in the firmware, pretty much the same ones as on the M50, so it's definitely worth trying.
If it works, it may provide a way to execute code on newer cameras cameras without hardware hacks, and without us having to break the encryption. Which hopefully keeps us safe(r) from the DMCA as well, but IANAL :)
That is, it might be possible to enable the boot flag directly from a Canon Basic script. At least, the execution context looks relatively safe at first sight (outside LiveView, with GUI locked up).
Quote from: yourboylloyd on September 02, 2020, 06:41:18 AM
I'm using a 128gb lexar card. I don't have anything smaller nor do I know how to make my card "look smaller."
You could write our QEMU card image to the card, which will shrink the filesystem to 256MB (FAT16 iirc):
Quote from: a1ex on January 25, 2016, 09:29:53 AM
Formatting a larger card at a much lower capacity (e.g. 256MB) does the trick. For example, you can write the SD image that comes with QEMU (https://foss.heptapod.net/magic-lantern/magic-lantern/-/raw/branch/qemu/contrib/qemu/sd.img.xz) to your SD or CF card (follow this guide (https://thepihut.com/blogs/raspberry-pi-tutorials/17789160-backing-up-and-restoring-your-raspberry-pis-sd-card)). This image contains the portable display test (http://www.magiclantern.fm/forum/index.php?topic=14732) and is bootable (so, you can test it in the camera straight away).
To verify it, test the card on any other ML-enabled camera. Once that works, make the card scriptable by following CHDK instructions (EosCard or whatever), then start the camera, go to PLAY mode and press SET. At least, that's what I did on M50.
I can also prepare a scriptable card image with Canon Basic dumper, if needed.
Interesting. I knew the M50 was hybrid Powershot / EOS, so there it makes sense, but I'm surprised about R! Maybe they've merged their code bases?? Or maybe all mirrorless use the hybrid code base, that could make sense?
If your suggestions don't work, I've got a Canon Basic disk image confirmed to work on my G15 that I can probably send a script to @yourboylloyd that'll write to a card via Linux VM.
Quote from: yourboylloyd on September 01, 2020, 11:49:20 PMSo it looks easy to get to. The problem is that the pins are extremely tiny. I'm going to try to measure the distance between them once I get a good battery for my calipers. But it's so small that I probably won't be able to tell if the pitch was between 0.4mm or 0.3mm or something.
Oh, so looks that my guess was right 8) We just need an confirmation, but the pitch basically confirms that.
Between 0.35 and 0.4mm according to my measurements on R (https://www.magiclantern.fm/forum/index.php?topic=22770.msg212069#msg212069). Thus I'd expect same pinout, as I don't see them having set of identical but differently wired interfaces.
As for EOSCARD, be sure it's not formatted in exfat. I forgot that yesterday when upgrading R to latest FW. Good news is that bootflag persisted, and dumper still works on 1.7.0 (https://www.magiclantern.fm/forum/index.php?topic=22770.msg230323#msg230323)
Quote from: a1ex on September 02, 2020, 07:14:30 AM
Guess what: the EOS R has some Canon Basic scripts in the firmware, pretty much the same ones as on the M50, so it's definitely worth trying.
Oh, that's why you asked :) Nope, but I'll try later today.
Quote from: names_are_hard on September 02, 2020, 08:03:09 AM
Interesting. I knew the M50 was hybrid Powershot / EOS, so there it makes sense, but I'm surprised about R! Maybe they've merged their code bases?? Or maybe all mirrorless use the hybrid code base, that could make sense?
IIRC R and M50 bootloaders were identical. For the firmware I have no clue.
Quote from: a1ex on September 02, 2020, 07:14:30 AM
You could write our QEMU card image to the card, which will shrink the filesystem to 256MB (FAT16 iirc):
To verify it, test the card on any other ML-enabled camera. Once that works, make the card scriptable by following CHDK instructions (EosCard or whatever), then start the camera, go to PLAY mode and press SET. At least, that's what I did on M50.
I can also prepare a scriptable card image with Canon Basic dumper, if needed.
I have an R5 here and just tried to get this working without luck so far. I did the following:
- Low level formatted a 128GB SD card in the R5
- On my PC I then wrote the QEMU SD card image to it using Win32 Disk Imager, verified the card was showing as 256MB
- Checked the card worked as expected in my 5D3
- Used EOScard 1.40 to set the card as scriptable (by ticking SCRIPT, unticking EOS_DEVELOP and BOOTDISK, then choosing "Save")
- Created a script.req file containing the string "for DC_scriptdisk"
Created an extend.m file containing Hello World (https://chdk.fandom.com/wiki/Canon_Basic/Scripts/HelloWorld2)- Created an extend.m file containing the dumper script
- Put the card in the camera, powered up, pressed Play followed by Set (also tried Play followed by Q)
Unfortunately nothing happens. Have I made a mistake or are we out of luck? Maybe there's a different combination required to trigger the script?
Quote from: a1ex on September 02, 2020, 07:14:30 AM
To verify it, test the card on any other ML-enabled camera.
Unfortunately I sold my t3i and all I have is a CFcardaccepting 5d2. I won't have a way to verify.
Quote from: a1ex on September 02, 2020, 07:14:30 AM
I can also prepare a scriptable card image with Canon Basic dumper, if needed.
That would be awesome probably. Especially since we're in two different time zones and it would be harder to communicate (bedtime was 2 hours ago for me :D ).
I actually do want to learn how to do it though so I'll probably follow your instructions anyway.
Canon basic dumper works on R! Not sure if without bootflag enabled too.
I created the files with Unix line endings (LF only). I made card by using EOScard, with only option "script" selected.
Both files (extend.m and script.req) you can download here: https://kitor.pl/eos_r/cbasic_dumper.zip
Of course credits for dumper goes to @srsa as I took his code directly from this post (https://www.magiclantern.fm/forum/index.php?topic=23296.msg227190#msg227190)
After I put card into camera, I went into playback mode, pressed Q/Set button and red light turned on. A minute later it was done, ROM.txt was saved to card root!
Quote from: chris_overseas on September 02, 2020, 08:51:08 AM
Unfortunately nothing happens. Have I made a mistake or are we out of luck? Maybe there's a different combination required to trigger the script?
Sure the SD Card is not exfat?
You need FAT.
Quote from: c_joerg on September 02, 2020, 11:06:42 AM
Sure the SD Card is not exfat?
You need FAT.
Yes, it's FAT
On my M100, the basic scripts only start every second time (on average).
There has to be some kind of temporal behavior.
The R5 and R6 have two card slots. In the firmwares I've seen, the extend.m script is expected to be on drive B: . Single card models seem to map their SD slot to B:
Of course, it's possible that scripting is not available on these models, or, they may have changed something to hinder 3rd party research.
@yourboylloyd
The UART likely uses 1.8V signalling level, your 3.3V and 5V adapters won't work on that. @kitor can probably recommend a compatible hw.
Quote from: c_joerg on September 02, 2020, 03:01:36 PM
On my M100, the basic scripts only start every second time (on average).
I don't remember seeing that on my cameras. If the script card is prepared correctly, the script can be started reliably.
QuoteThe UART likely uses 1.8V signalling level, your 3.3V and 5V adapters won't work on that. @kitor can probably recommend a compatible hw.
I did simple voltage divider on TX of my usual 3v3 UART, RX was able to pick 1v8 leves fine. Judging by old photo, I used my CH341A based UART:
https://twitter.com/_kitor/status/1095729715284008960
Quoteor, they may have changed something to hinder 3rd party research.
That's why I updated R to latest 1.7 - we know that at least there it wasn't removed.
Quote from: yourboylloyd on September 01, 2020, 11:49:20 PM
Does anyone have advice on a way to probe the pins? I have an arduino uno, usb host shield, FTDI USB UART IC 'FT232RL' adapter that can run at 3.3V or 5V, and all the accessories that come with an arduino (breadboard, wires etc). But I don't know how to make a connector that could probe pins that are that small.
I've got the FT232RL adapter, and can confirm it can listen to 1.8V signals via its RX pin, with the jumper set to 3.3V. That's the easiest way to probe for the UART, in my opinion:
- connect the GND pin between FT232 and camera
- use the FT232 RX pin to probe around, while watching the Arduino serial monitor (a needle could be handy)
Expecting a bunch of messages right after camera startup, but also while in LiveView, for example.
TLDR: initial probing can be done with only the GND and RX pins from the FT232 adapter.
For sending messages to the camera, via the FT232 TX pin, you will need a voltage divider, as suggested by Kitor. When you reach this step, you may want to join the chat room :D
Quote from: coon on September 02, 2020, 12:48:38 AM
I am going to try out the Jtagulator: http://www.grandideastudio.com/jtagulator/
This device can scan up to 24 pins simultaneously and figures out the pinout of UART or JTAG. You can also set the voltage via software at which the device scans the pins (pretty handy for 1.8V pins).
It is a bit expensive but it is also open source so I will solder it by myself within the next few days.
I will let you let you know once I've tried that out but first the PCB and the parts needs to arrive...
What about the connectors and the FPC cable itself? any ideas?
I went the hard way with R, and probed testpoints with needle soldered to wire, that was connected to UART TX. Yes, this required removing whole back case.
Later, I used 0.5mm pitch FPC, just removed all unused pins, and tried to slightly shrink those needed ones so they won't short nearby pins.
You can deal with GND by just taking it from any outside connector, like USB case - instead of having it on ribbon. It's easier to deal with two instead of three pins.
Anyway, I'd try Canon Basic again. No disassembly needed, and it's confirmed to work on R and RP... so there's a high hope getting there without disassembly. Just check in both slots, as it was mentioned that it needs to be B:\, which we have no idea how maps two slots to letters in R5/R6.
Quote from: chris_overseas on September 02, 2020, 08:51:08 AM
I have an R5 here and just tried to get this working without luck so far. I did the following:
- Low level formatted a 128GB SD card in the R5
- On my PC I then wrote the QEMU SD card image to it using Win32 Disk Imager, verified the card was showing as 256MB
- Checked the card worked as expected in my 5D3
- Used EOScard 1.40 to set the card as scriptable (by ticking SCRIPT, unticking EOS_DEVELOP and BOOTDISK, then choosing "Save")
- Created a script.req file containing the string "for DC_scriptdisk"
Created an extend.m file containing Hello World (https://chdk.fandom.com/wiki/Canon_Basic/Scripts/HelloWorld2)- Created an extend.m file containing the dumper script
- Put the card in the camera, powered up, pressed Play followed by Set (also tried Play followed by Q)
Unfortunately nothing happens.
I tried everything on the R6. I can confirm this isn't working either.
My card is 256mb. I used EOSCARD to make sure it was scriptable. Pressed PLAY and then SET = Nothing. Pull Out battery. Pressed PLAY and then Q = Nothing. Repeat for PLAY and then (EVERY OTHER BUTTON ON THE CAMERA) = Nothing.
I tried Card slot 1 and then card Slot 2.
Maybe I should try having 2 cards with the same script on them in both slots? Any ideas?
Edit: I just counted and found that there is a total of 26 buttons (including dials and joystick directions) on the R6. Assuming that there are 2 input combinations to start the script, there are a possible 26x26 = 676 combinations that are possible to be the solution XD
If no one else has a better idea, I'll get to fingering.
Edit 2:
Quote from: srsa on May 16, 2020, 05:05:44 PM
edit:
It turned out that there are better ways to dump ROM content - I can tell what they are if anyone is interested.
Does anyone know what that "better way" is? I sent srsa a PM asking about it.
Quote from: yourboylloyd on September 04, 2020, 03:20:42 AM
Edit: I just counted and found that there is a total of 26 buttons (including dials and joystick directions) on the R6. Assuming that there are 2 input combinations to start the script, there are a possible 26x26 = 676 combinations that are possible to be the solution XD
Or a combinaton with touchscreen ;)
Quotehttps://chdk.fandom.com/wiki/Canon_Basic/Card_Setup
Some touchscreen cameras run the script when the focus lever is turned to the left.
Quote from: c_joerg on September 04, 2020, 07:38:29 AM
Or a combinaton with touchscreen ;)
You gotta be kidding me... I didn't even think of that.
Quote
Some touchscreen cameras run the script when the focus lever is turned to the left.
What does that even meannn??? A focus lever?? Do I have to focus my lens at infinity? Or close focus? Does it have to be a canon lens? What if the lens is manual focus?
Whatever I'll try whatever I think it's saying and report back.
Edit: I tried focusing at close focus, half way, infinity, infinty and beyond. Multiple lenses. Multiple cardslots. The SET button. The Q button. Nothing.
You may be not aware that most PowerShot code-based cams don't have something like a focus ring but rely solely on remote focus control and this hack srsa most kindly introduced to us is born in the CHDK realm...
And: No, I don't have any idea if this focus thingy applies to R-cameras and (in case it does) how to handle this requirement. ;-) And I suspect he's acturally referring to "zoom lever".
Quote from: yourboylloyd on September 04, 2020, 03:20:42 AM
Does anyone know what that "better way" is? I sent srsa a PM asking about it.
Replying here.
I added that edit before making the new thread about scripting. The 'better way' is nothing more than the two short dumper scripts in the first post of the new thread.
As for the lack of success running scripts on R5/R6, I still tend to think that Canon has changed some details in their script related code or even decided to remove it altogether.
So, IMO, the current way to go ahead is the UART.
:)
https://www.diyphotography.net/take-a-peek-inside-the-canon-eos-r6-mirrorless-camera-in-this-disassembly-and-teardown/
:)
https://petapixel.com/2020/09/04/teardown-reveals-overheating-timer-chip-inside-the-canon-eos-r6/
CANON BASIC DUMPER WORKS ON THE R6!!!! I'VE SUCESSFULLY RAN THE SCRIPT ON THE R6 Firmware 1.1.0
First:
I borrowed my friend's M50. Using Kitor's card image, I tried to run the same script on the 128gb SDXC card that I used for my R6 trials. I found that it wasn't working. So I knew something was up.
Second:
I went to walgreens and bought a $20 16GB SDHC-I card (why was that so expensive for 16 gigabytes?? I mean c'mon!) and I tried to run the script on the M50 again using that card. It worked on the M50!! I was given a boot00.bin file
So I figured it had work on the R6. I deleted the bin file and tried it on my R6. I put the SD card in the second card slot (the one labled 2). Turned it on. Pressed PLAY and then SET. Then the card LED turned RED and Voila! boot00.bin file!!
TLDR: SDXC cards don't work for some reason. The script also DOES NOT WORK in Slot 1 at all. Use SDHC cards to dump rom images. Thanks to Ant123 and Walter for the idea to use a different card! And Kitor for the image.
Edit: I ran the SaveAllRomImageToFile() script that was in srsa's example scripts and I was left with two files. gang100.bin (65,536KB) and gang200.bin (32,768KB).
Congratulations!
:)
Very nice - I can confirm it works on the R5 too! I had been using an SDXC card with my previous attempts, worked fine when I tried it with an SDHC. Same combination to activate it, PLAY then SET.
This is awesome!
Does anyone have any idea why SDXC wouldn't work?
It's easy to guess a bunch of reasons why, but it doesn't really matter.
Since SDXC tend to be larger cards, I'd like to test the theory that it's not SDXC, but really the size of the card that matters. Apparently there are 32GB SDXC cards, so if 64GB SDHC can be shown to work, and 32GB SDXC shown to not work, on the same cam, then it's probably SDXC being the problem. Again, doing this test isn't important - we know small-ish SDHC works, and that's easy to do.
There is a mixup of terms.
SDHC is limited to card sizes up to 32 GByte. Any larger card is - by definition - SDXC.
I think you meant to talk about partition size and want to experiment with that.
No, I was just making a bad assumption, I thought SDXC was a speed / bus change :)
Could easily be some size check then, if it's done on the disk, not the partition. Could still test a 32GB version of SDHC and SDXC.
Good luck finding a 32 GB SDXC! 8)
https://www.sdcard.org/consumers/choices/file_system/index.html
I don't say they don't exist ... https://www.dpreview.com/articles/0658120146/pretecsdxc
just hard to find and old GByte vs. GiByte mixup doesn't really help ...
Probably easier to reverse the rom to find out the reason :)
Okay, all this dumping was a lot of fun!
Where to go now? There are some people looking for a solution to deal with R5/R6's timers. And srsa opened the way to run a command set by just pressing 2 keys.
Easy to poke some unwanted registers, too.
Canon Basic can do a lot more as you can see from these tread.
https://chdk.setepontos.com/index.php?topic=13522.0
This is a M100 snapshot of a Canon Basic Script that I got from srsa.
(https://live.staticflickr.com/7829/46750428704_4f3a71e117_c.jpg) (https://flic.kr/p/2eebaGd)
Perhaps this could also be used to make the temperatures of the R5 visible
Quote from: names_are_hard on September 05, 2020, 07:33:21 AM
Probably easier to reverse the rom to find out the reason :)
I assume that on SDXC cards the system uses a separate driver / library for EXFAT, which is loaded after checking the card for a signature.
I have the opposite situation with the EOS M3: I would not want to buy a SDXC card if it does not work with a CHDK.
Perhaps the same situation will be with ML when (and if) it will be implemented for new cameras.
Quote from: c_joerg on September 05, 2020, 08:21:41 AM
Perhaps this could also be used to make the temperatures of the R5 visible
What are you waiting for? The string in Canon's code is most likely EFIC_TEMP and there is a script to decompile ROM contents*. I don't have the time right now to do that. I'm not a programmer but this looks like an easy task.
*Dang! It is not yet confirmed to work with Digic X! a1ex?
Walter Schulz
You should understand that EOS M100 uses PowerShot based firmware and Canon Basic command set could be different for EOS R. Finding a string in a ROM dump doesn't mean that it can be easily accessed with Canon Basic, especially without testing it on a real camera.
I have a feeling that with R5 Canon may have created the spark that this project needed to move forward :)
Quick break in that we achieved when topic is hot may help that.
Looks that R5 may really become next 5D2.
I found crazy that the RTC is a dedicated chip place in the middle of nothing and so easy to access.
I have a simple question.
The RTC holds the time and day and can be access by the I2C bus. Either to program the time and the alarm and countdown.
But when a alarm is set up, Pin 6 is the IRQ line. Usually, the IRQ adk the processor to check what is happening by reading the I2C.
Is simply cutting the pin 6 signal enough for not triggering the IRQ signal and shoot forever? (and keep time of the day and date active?)
You need to have this pin a High level with a pull up resistor linked to pin 8 if it's not already the case (low level is IRQ Active)
Quote from: visionrouge.net on September 05, 2020, 01:56:54 PM
I found crazy that the RTC is a dedicated chip place in the middle of nothing and so easy to access.
I have a simple question.
The RTC holds the time and day and can be access by the I2C bus. Either to program the time and the alarm and countdown.
But when a alarm is set up, Pin 6 is the IRQ line. Usually, the IRQ adk the processor to check what is happening by reading the I2C.
Is simply cutting the pin 6 signal enough for not triggering the IRQ signal and shoot forever? (and keep time of the day and date active?)
You need to have this pin a High level with a pull up resistor linked to pin 8 if it's not already the case (low level is IRQ Active)
Thanks for the info & your time that you invested.
Quote from: visionrouge.net on September 05, 2020, 01:56:54 PM
Is simply cutting the pin 6 signal enough for not triggering the IRQ signal and shoot forever? (and keep time of the day and date active?)
If it was your question my answer is "no".
The processor has enough timers to count the heat and RTC is needed only when camera is powered off.
On EOS R cameras RTC probably can be used to wake up the camera (https://chdk.setepontos.com/index.php?topic=12542.msg137085#msg137085).
Anyway cutting PCB lines is bad idea. It's better to wait for a software solution.
If cutting the lines would work I would still mod the Hardware.
Well, it may be a bit more complicated.
If you put some fact together:
-Removing the battery cell reset the fake overheat timer, reset the time and date and few shooting parameters, but keep others as custom functions. So a memory is also powered with this battery. This is very common and few RTC chip also have internal memory to do 2 functions in one (RTC+limited amount of parameters)
This RX8130 do not have a memory register. So it have to be another chip somewhere to do so.
-The amount of chip powered by the 3.3V cell have to be as limited as possible and more likely close to the cell area. This is to keep backup, the power usage should be as tiny as possible. It uses 300 Nano Ampere in sleep mode as reference.
-If it was only a countdown with an IRQ, removing the battery during during the recording and putting back should not affect the countdown. The counter should keep running as soon as the "power good" is restored. So again, it points out to another memory that hold the counter flag.
I still believe a solution as magic lantern is the best way to go.
Either the counter inside the RTC is used for the fake overheat warning, Either it's just a RTC for the time and date.
A chip with a memory along the power line coming from the cell battery is more likely to have a register that can be access and changed by a side software. This software is extremely simple and write time to time a 0 flag in the fake overheat register.
The fake overheat timer starts during the full power state and write a flag when a normal internal timer is reached. This is more likely than using a specific chip for that. Only because the flag is written at the end of the count that removing the battery during shooting allows to restart. So finding this flag and overwriting it will solve this.
I don't see a use of this RTC for overheating purpose as it have very limited alarm feature. (The overheating have 2 steps for example)
I really see a register powered by the 3.3V, so a unique chip alone, not part of any large IC, that holds the key.
That should be also easier to access as it's a dedicated chip, ore likely from a generic brand more than from Canon, so the way to access it should be in a pdf somehow.
Sorry that I can't modify my post.
Ok, here are new thouht after thinking a bit.
Something is bothering me is the recovery time.
Even without regular camera battery, or by pushing the time.
The recovery time is not reduced.
If it was just a flag to a memory that start to count, it will not be able to know how long the camera was actually off.
It have to be a counter, not just a date stamp difference.
This overheat counter IS inside this chip for sure. cause it can't hold 2 different date and the internal counter are quite limited.
Either the current overheat time is written inside a eeprom, and so compare on boot, either there is a timer that keep running even without battery.
After 2 hour of "fake cool down"; the camera is powering again and check the value of this counter. If it reached the end, you can go again. If not, you have to wait.
The second possibility is that the camera compare the time on boot and do a simple subtraction to know if the elapsed time is enough. The various test kind of shows that it is not working.
To make sure about the second possibility and twist it a bit
I would love someone to do a simple test.
Put the camera on overheat and lock (after 20mn recording video) and keep the battery door open with the scerw hack or use dumb battery the entire time
Change the date or time to move it to the next day.
Now, try 2 different things:
Remove the camera battery with the drop system. Is restarting check the new day? (But not the flag?)
Or simple turn off the camera, remove the battery and start again. is the second restart is able to do the math between both time? (So the overheat time is stored on eeprom/a counter is runnin during no battery time)
Does it makes sense to test this?
Quote from: visionrouge.net on September 06, 2020, 06:16:36 AM
I would love someone to do a simple test.
Put the camera on overheat and lock (after 20mn recording video) and keep the battery door open with the scerw hack or use dumb battery the entire time
Change the date or time to move it to the next day.
Now, try 2 different things:
Remove the camera battery with the drop system. Is restarting check the new day? (But not the flag?)
Or simple turn off the camera, remove the battery and start again. is the second restart is able to do the math between both time? (So the overheat time is stored on eeprom/a counter is runnin during no battery time)
Does it makes sense to test this?
I'll do it now on my R6 and a dummy battery.
GOOD NEWS!!
Results:
- I let the camera overheat after 29:59 + 8:07 mins of recording. Was not able to record anything
- I changed the date and time to one day later and confirmed then went back to canon menu
- Dummy battery disconnect immediately after changing date and time
- Overheating times seems to have reset. The date and time that was changed saved on reboot. All footage was recorded to the SD card successfully
- I proceeded to record in a cooler room. It recorded for 29:59 + 13:03 then overheated. So being in a cooler room did help
- I then disconnected the dummy battery WITHOUT changing the date and time +1 day. I turned the camera back on and the overheating warning was still there.
- I also tried changing the date +1 day and then waiting a few seconds in liveview, then battery pull. The overheating warning was still there.
- I changed the date +1 again and immediately removed the battery. Voila. Overheating timer gone! All other settings saved.
TLDR; basically, unlimited record time. All footage saved. If camera is overheating, change date +1 day and immediately pull dummy battery to reset overheating timer. Thanks visionrouge(dot)net for the idea! This makes using this camera extremely worry free professionally for me. I wonder if we can make a script that can emulate those steps to trick the overheating timer. I encourage someone else to replicate this test on R6 and R5
*It must be noted that I have bootflag enabled on my EOS R6. Not sure if it means anything in relation to this test.
** It also must be noted that the files were split into 4GB files. I'm not sure if that's the default setting because I've never recorded that long. I realized that I formatted my 128GB card as FAT32 instead of exFAT so this makes sense.
I'm so happy!
Thanks for trying.
YES!!!!
Please quote my company for such! :) :) :) :) :)
So, the camera DO a simple time difference between the actual last overheat and the actual time, but as you drop the battery, the time change bit is not read.
The boot just read the time present in the RTC at this time.
I guess the software engineer have applied a filter to not do a time difference if the day/time is changed, but this is bypassed by this kind of boot.
It also shows the RTC do not run a overheat timer when camera is off.
The compilation of finding are online https://www.visionrouge.net/canon-r5-overheating-hack-solved/ (please click on the advertising at the botom to offer me 5 cent, I may be able to buy a new SD card !)
(And getting updated right now with pictures and all)
I'm so excited to find such loophole.
We need more R5 test with regular card, but I don't think there are relationship between this and the drop power boot.
I love you all
Cool hack - it's the clearest proof the "overheating" is timer-based, if you ask me.
Quote from: Walter Schulz on August 19, 2020, 07:18:35 PM
As I said: IMO this would be *the* opportunity to make transition to pay-for-ML-feature-development work.
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 (https://twitter.com/autoexec_bin/status/1302579709683826694)). 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.
On the other hand, this "overheating" thingie caused quite a stir on the internet, which ended up drawing some of the attention (https://twitter.com/_kitor/status/1302211871651622913) towards our project. That's probably "exploitable" in the sense of "pay-for-development", but primarily for the other models - if I'm not mistaken, the R5 already records 8K raw video (but I haven't touched this camera, so I might be wrong), so the motivation for our enhancements on this model is probably low, besides the overheating timer hack.
Now, back to my (covid-related) research :)
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 (https://twitter.com/autoexec_bin/status/1302579709683826694)). 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 :)
Automation of the time change would be simple - only requires an HTTP GET and PUT over WiFi to "http://<camera ip>:8080/ccapi/ver100/functions/datetime". See my Canomate CCAPI utility at Canomate HomePage (https://www.testcams.com/canomate/) and Canomate GitHub Repository (https://github.com/horshack-dpreview/Canomate) for examples on usage. Canomate's SyncDateTime (https://github.com/horshack-dpreview/Canomate/blob/5123b13e28ca94de727a0ecc252ac456fbc06ffd/canomate.py#L923) does this.
Automation of the battery pull word require scripting to a network-enabled power switch, like a TP-Link Kasa Smart Plug (https://www.amazon.com/TP-LINK-HS103P2-Required-Google-Assistant/dp/B07B8W2KHZ), connected to a dummy battery (https://www.amazon.com/Adapter-Gonine-Coupler-Battery-Replacement/dp/B01D68YXOQ) inside the camera.
Both could be implemented via a simple Smartphone app.
Quote from: horshack on September 06, 2020, 04:04:59 PM
Automation of the time change would be simple - only requires an HTTP GET and PUT over WiFi to "http://<camera ip>:8080/ccapi/ver100/functions/datetime". See my Canomate CCAPI utility at Canomate HomePage (https://www.testcams.com/canomate/) and Canomate GitHub Repository (https://github.com/horshack-dpreview/Canomate) for examples on usage. Canomate's "SyncDateTime" does this.
Automation of the battery pull word require scripting to a network-enabled power switch, like a TP-Link Kasa Smart Plug (https://www.amazon.com/TP-LINK-HS103P2-Required-Google-Assistant/dp/B07B8W2KHZ), connected to a dummy battery (https://www.amazon.com/Adapter-Gonine-Coupler-Battery-Replacement/dp/B01D68YXOQ) inside the camera.
Both could be implemented via a simple Smartphone app.
You can go further.
When overheating.
Put the time front one hour. Do a battery drop.
The overheat timer is gone, so you need to write this flag down by turning off the camera.
When done, you can now change back the real time. As the flag is gone, there is no more check on "how long it is before cooling"
If you know how long each step are taking and add the exact same amount of time, you may actually always record with the real time.
The reset sequence can include a go back in time sequence...
Quote from: a1ex on September 06, 2020, 03:26:24 PM
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.
a1ex speaking from my experience, I think there are enough users who would be willing to pay for the development. For porting ML to 5Dm4 or even R5/R6. And this would be really the best time for the switch -- there's a lot of interest around R5/R6. And it's not just the timers...
I've been professionally shooting ML raw with 5D3 for years. The 5x3 48p is dated, but there are still not many other options. Blackmagic has BRAW (not raw), cropped sensors, and plastic bodies. Sigma FP is nice but quite limited and the fullHD line-skipped mode is "meh"... Even if I would be willing to spend 10k+ on a Cinema Camera, the C300mk3 is still S35 only. And the C500mk2 is way out of budget of independent filmmakers and high-end documentarists like me.
There really are not many options that are full-frame with raw, sharp full HD and at least 48p. Not to mention that amazing UI of ML.
Recent developments with cropped 4k raw and gray preview are nice, but not so easy to use in a real-world for some serious work.
Maybe it's just me, but I really think focusing on the high-end camera will make much more sense. People who use EOS M are lowe-end hobbyists who most of them already switched to some other cheap cameras. If you will be able to port ML to 5Dmk4 (which is 1500 eur used) every film student and indie artist will use it.
The Canon 5d4 is surpassed by the sigma fp at least for me, I sold the 5dmk3 for the sigma.
I would be most interested in the r5 with magic lantern, because evf and tilting screen and usable autofocus makes it a smaller package not needing extra an extra monitor or evf.
What I would use magic lantern for is writing lens metadata for manual focus lenses and the recording timer automated.
Quote from: a1ex on September 06, 2020, 03:26:24 PM
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.
I wrote that way back in the days when ML was the only software offering a solution. Good old days, feels like yesterday ... wait ... It was kind of yesterday, wasn't it?
Totally agree! Doesn't make sense to put a price tag on some script.
But that wasn't my intention. ML going payware? Nope but I consider this a good starting point for something like Patreon.
Are there "enough" contributors like kaco wrote? Definitely don't know!
Here's a Canomate (https://www.testcams.com/canomate/) script for automatically changing the camera's clock to +1 day and then back.
Save the contents of the following to a file named DateTimeHack.txt:
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
To run the script: canomate.py --ip=<camera's IP address> --opfile=DateTimeHack.txt
Output:
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"
I tested this on my Canon RP.
I tried writing a quick JavaScript app that does this in a browser (so we can use portable devices like smartphones) but the Cross-Origin Resource Sharing (CORS) (https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) protections prevents the code from performing requests to the camera. Unfortunately the camera is not sending a permissible Access-Control-Allow-Origin in the HTTP header. A developer has already requested a change here: Could a CORS policy be implemented for the CCAPI? (https://developers.canon-europe.com/developers/s/question/0D50J00005vU25E/could-a-cors-policy-be-implemented-for-the-ccapi). This would have to be written as a Smartphone app instead. Shouldn't be too hard for an enterprising individual :)
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.
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.
Not viable for mobile solutions since extensions aren't allowed on those platforms. I'll be testing my Canomate with Pythonista (http://omz-software.com/pythonista/) later today.
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, 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 :)
Thanks. I can look into Android since I run both iOS and Android. An internet-based MITM proxy wouldn't work since it wont have access to the local phone's IP (unless the port is forwarded through the router and that wont work when away from home network). Running MITM on the phone would work but then you're writing an app anyway to do it. Running MITM on a computer on the local network would work but again not viable when not on home network.
I just tried Canomate with pythonista and it worked on both my iPad and iPhone. Bit of a hassle getting the .py files onto the phone (uploaded them to my Google Drive, then downloaded from Google Drive to Files app, then opened in pythonista). Here's a screenshot from the phone.
(https://photos.smugmug.com/photos/i-gBHnSMn/1/dde50d60/O/i-gBHnSMn.png)
Quote from: Lars Steenhoff on September 06, 2020, 07:31:06 PM
What I would use magic lantern for is writing lens metadata for manual focus lenses and the recording timer automated.
It would also be nice to know the real temperature if you disable a "safety timer".
Yes for sure, it would be good to know when the camera is really overheating based on the sensor and not on the timer.
@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.
No need for dummy battery boys and girls, just recorded in 8K IPB until the overheating warning came on. Changed the day +1 and pulled the battery. Voila! Canon Cripple Clock obliterated! Great work ppl!
I certainly think there would be plenty of interest in ML for the EOS R5 and R6.
The overheating timer patch is the big thing, but the file sizes in 8K RAW aren't really practical and not many people need 8K... So would be good to see what else RAW-related might be hidden in that frame buffer... 4K RAW or 3K crop perhaps....the write speeds to CFexpress would very likely allow 10bit lossless RAW in 4K! And to enable ALL-I and DCI 4K on R6 would be tremendous! And temps monitor in real-time, to check for any dangerous ones on hot days.
Well done to all testers and contributors on here, it's amazing the progress already.
I think ML should invest some Patreon money in useful hardware, non-profit organisation but able to invest in their mission. I'd happily support any Patreon.
And of course I want to play Arkanoid on my EOS R5 ;)
Quote from: Dmytro_ua on September 06, 2020, 10:11:16 PM
It would also be nice to know the real temperature if you disable a "safety timer".
There is a next step on this hack. I should work, but need one beta tester to be sure.
Follow the previous procedure to push forward the day.
When you see that the "overheat logo" is gone;
turn off the camera using power button.At this time, the "overheat flag" is now written into memory.
Turn back on the power with the power button. The camera is now booting from a regular boot.
So if you have no warning here, the camera is absolute fine with temperature. This not a "special boot" anymore
And the beauty of it, you can now push back the day as the actual day.So with this extra step, all your clip are even at the right time.
Can someone test this ? Thanks
I will update on visionrouge.net if so.
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.
Thanks. That's probably a bit too much to ask of somebody as a way around the CORS. Btw, how does that create a path between an internet-based CORS proxy and the camera?
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.
A poster on EOSHD got 75C (EXIF temp) after 38 minutes of 4K 120fps using @visionrouge.net's workaround. I think that's probably pushing it. It was hot enough to cause the R5's stills temp warning icon to show. He said the CFE was extremely hot when removed.
It works:
15 mins recording 8K ALL-I to CFExpress, overheating icon
Day +1, pulled battery
Inserted battery 30 secs later
No overheating icon
Turn off camera
Turn on camera, change date to current date, no overheating icon.
Quote from: dellfonic on September 07, 2020, 05:29:26 AM
It works:
15 mins recording 8K ALL-I to CFExpress, overheating icon
Day +1, pulled battery
Inserted battery 30 secs later
No overheating icon
Turn off camera
Turn on camera, change date to current date, no overheating icon.
YES!I love to be right. 8) 8) 8)
thanks for testing, you will have your name on my wall of fame too!
I'm wondering how Canon feel about a 40+ photographer able to crack their software without even having the camera in hand.
@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: visionrouge.net on September 07, 2020, 06:03:27 AM
YES!
I love to be right. 8) 8) 8)
thanks for testing, you will have your name on my wall of fame too!
I'm wondering how Canon feel about a 40+ photographer able to crack their software without even having the camera in hand.
Ha, great work mate, I'm slightly annoyed with myself for not coming up with the solution as it's my natural inclination to bend and push any kind of deliberate cripple! Then again, I have leased it out for the last 3 weeks, so presumed all the tests had been exhausted.
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.
I'm not following you. The client in this case is the browser running my test javascript code issuing REST API requests to the camera's REST API server (CCAPI). There is no way to coerce the browser to accept cross-domain requests unless the HTTP header response from the server contains an Access-Control-Allow-Origin response that specifically allows the domain you're requesting from. The only way around that is either an extension running in the browser that hacks an Access-Control-Allow-Origin field in the response header (doesn't work on iOS because extensions aren't allowed) or by issuing the REST API request through a CORS proxy that issues the request to the intended target on your behalf (camera in this case) and returns a response that adds in the Access-Control-Allow-Origin field. I don't see how running a VPN factors into the equation as a solution.
Canomate doesn't have this issue because it runs as a Python app outside the browser. I tried implementing a REST API client as javascript instead for this specific date/time R5/R6 workaround as a lightweight alternative to running Canomate and also because it would be a portable solution that can run in a Smartphone browser.
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: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.
The only device is the smartphone running in the field. Where is proxy code running that has IP access to the camera?
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: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.
Canon's REST API only runs over its WiFi interface. Using the phone as a hotspot so that an external site could gain access to the camera (ie, one of the existing CORS proxies available online) would require the phone to port-forward unsolicited incoming requests to the camera, the same as a router NAT would. iPhone's don't have NAT functionality for their hotspot feature as far as I'm aware. And if it did it wouldn't require a VPN.
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, 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.
iOS's hotspot implementation doesn't support that configuration. If the demand is there the easiest solution is a standalone smartphone app. Canon actually provides the source for a fully-functional proof-of-concept CCAPI Android app. I have no interest in developing for Android though. It's likely a small effort to modify the source. Anyone interested can download the Android app source here: https://developercommunity.usa.canon.com/canon?id=sdk_download. You'll need to register on the site to gain access to the download - registration is free.
Ugh, Apple. They never let you do anything fun.
Quote from: horshack on September 07, 2020, 05:03:43 AM
A poster on EOSHD got 75C (EXIF temp) after 38 minutes of 4K 120fps using @visionrouge.net's workaround. I think that's probably pushing it. It was hot enough to cause the R5's stills temp warning icon to show. He said the CFE was extremely hot when removed.
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.
I'm posting here as reference y best guess why my hack is working.
It may be useful for a possible software side app at one point.
Canon do a very simple calculation.
When camera is running, a counter is setup. When the counter reach a certain level, you have a warning logo.
If you keep recording, the Logo will become a shut down. This raise a flag that I will call "Fake Overheating flag"
At each of these step Canon is writing the exact time this occurs. Let's call it the "overheat start time".
This is done in an EEPROM that is kept even if you remove the battery. The writing occurs when you shut down with the power button. This is the mistake right there.
There are only one way of getting the camera to work again is to wait extra time.
Canon do a simple calculation between "actual time" and "overheat start time". This way, even if the camera is off without battery, they can keep the time running with the help of the RTC.
It's a way of doing coding something very fast.
They also put a conditional test on "Fake Overheating flag" to make sure changing the time during the overheat mode will not change this calculation. My best guess is that they modify the "overheat start time" with the same value the camera time is shifted in this condition only. So each tentative to play this way is not working.
But I have the impression that the new"overheat start time" is written ONLY when the camera is power down. The new real time is written immediately.
So by dropping the battery, you are avoiding the "overheat start time" to be written and only the last one is in the memory.
When the power is restored, there is the calculation to see if you have been waiting enough. But based on the old "overheat start time", not the one shifted by the time modification. BOOOOM.
So the "Fake Overheating flag" is now remove and the camera can start.
Even better, The camera is writing this new "Fake Overheating flag" value into the EEprom. So you can turn off the right way and it will restart without any problem.
You can now shift the time back, there is no check for a possible "overheat start time" cause we are not supposed to be in overheating mode.
So whatever card you are using, whatever R5 or R6, whatever firmware... it's working.
That was my idea at first when I noticed that the battery drop do not save all parameters. An yes, it works so beautifully.
Quote 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.
Agreed, SD is likely the better choice for video modes that don't require CFE's speed. It would be nice to see a well-controlled temperature comparison test between SD and CFE for a long-run 8K video (comparing EXIF temps).
Someone posted to EOSHD forum that they didn't need a dummy battery or a door closed hack to reset the timer.
I can't confirm the test of the regular battery pull on the EOS R6. No matter how many times I try, the overheating light never goes away (even when I take it out super quickly). I have to use a dummy battery or a "battery door close trick hack."
Quote from: dellfonic on September 07, 2020, 05:29:26 AM
It works:
15 mins recording 8K ALL-I to CFExpress, overheating icon
Day +1, pulled battery
Inserted battery 30 secs later
No overheating icon
Turn off camera
Turn on camera, change date to current date, no overheating icon.
I can confirm this hack on EOS R6. Set date +1 day, then battery disconnect, turn camera back on, date -1 day does work. The timer has officially been reset and I am able to have clips saved on at the correct time.
I was actually at the beach filming 4K 60fps all day. Of course I got the overheating warning but this hack has so far been able to practically save my life haha!
Quote from: yourboylloyd on September 07, 2020, 10:34:36 PM
Someone posted to EOSHD forum that they didn't need a dummy battery or a door closed hack to reset the timer. I can't confirm the test of the regular battery pull on the EOS R6. No matter how many times I try, the overheating light never goes away (even when I take it out super quickly). I have to use a dummy battery or a "battery door close trick hack."
I can confirm this hack on EOS R6. Set date +1 day, then battery disconnect, turn camera back on, date -1 day does work. The timer has officially been reset and I am able to have clips saved on at the correct time.
I was actually at the beach filming 4K 60fps all day. Of course I got the overheating warning but this hack has so far been able to practically save my life haha!
Firmware version?
I can confirm this as well, no need to defeat the battery door sensor!
Just change the date and pull the battery as normal.
You can put the date back to the correct one upon reinserting battery.
Updated instructions:
https://www.eoshd.com/news/magic-lantern-users-create-practical-canon-eos-r5-overheating-timer-workaround/
I've created a web-based javascript app that lets you quickly set the camera's clock to +1 day and -1 day to help automate visionrouge's workaround. It only works in browsers that allow you to disable CORS Policy Security (https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS). Unfortunately none of the mobile web browsers available support that option, so for now this is limited to home/office/studio use.
Here is the link to the app: http://www.testcams.com/ccapi/datehack.html
Full instructions including how to disable CORS Policy security are in the GitHub repository: https://github.com/horshack-dpreview/canondatehack.html
Quote from: 71m363nd3r on September 08, 2020, 02:01:01 AM
Firmware version?
R6 v1.1.0 . That's the only firmware version for the R6 currently
Quote from: EOSHD on September 08, 2020, 02:11:22 AM
I can confirm this as well, no need to defeat the battery door sensor!
Just change the date and pull the battery as normal.
You can put the date back to the correct one upon reinserting battery.
No I was literally saying that DOESN'T work for me. I CAN'T get that working on the EOS R6 no matter how many times I try or how fast I try it. I NEED a battery door hack or a dummy battery in order for it to work. It doesn't work on a regular battery pull.
Quote from: horshack on September 08, 2020, 08:08:09 AM
I've created a web-based javascript app that lets you quickly set the camera's clock to +1 day and -1 day to help automate visionrouge's workaround. It only works in browsers that allow you to disable CORS Policy Security (https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS). Unfortunately none of the mobile web browsers available support that option, so for now this is limited to home/office/studio use.
Here is the link to the app: http://www.testcams.com/ccapi/datehack.html
Full instructions including how to disable CORS Policy security are in the GitHub repository: https://github.com/horshack-dpreview/canondatehack.html
Thanks Horshack. You're awesome
Quote from: yourboylloyd on September 08, 2020, 08:18:38 AM
R6 v1.1.0 . That's the only firmware version for the R6 currently
I have checked and my R6 has software version 1.0.0
I am not technically involved in this topic. But if I can do something helpful, I'd love to!
Quote from: Chainstone on September 08, 2020, 01:14:17 PM
I have checked and my R6 has software version 1.0.0
I am not technically involved in this topic. But if I can do something helpful, I'd love to!
Your PC: Mac or Windows or Linux?
And would you mind testing timer hack following the steps provided by EOSHD (https://www.eoshd.com/news/magic-lantern-users-create-practical-canon-eos-r5-overheating-timer-workaround/)?
Quote from: Walter Schulz on September 08, 2020, 02:13:49 PM
Your PC: Mac or Windows or Linux?
I have access to both. Mac and Windows.
Not directly to Linux at the moment, but probably could be changed if necessary.
Quote from: yourboylloyd on September 08, 2020, 08:18:38 AM
No I was literally saying that DOESN'T work for me.
No offence but would you mind recording a video following the steps shown in video provided by EOSHD?
None taken Walter. Will do sometime tonight.
https://www.lensrentals.com/blog/2020/09/taking-apart-the-canon-r5-mirrorless-camera/
Teardown of the R5
Quote from: Chainstone on September 08, 2020, 01:14:17 PM
I have checked and my R6 has software version 1.0.0
I am not technically involved in this topic. But if I can do something helpful, I'd love to!
Yes you can help if you have firmware version 1.0.0. I'll give you some steps below on how to perform a ROM dump.
1. Get a SD or a SDHC card on standby. An SDXC card won't work.
2. On a PC, download and install this program (https://sourceforge.net/projects/win32diskimager/)
3. Also download this link (https://drive.google.com/file/d/1eMcuERvIoRDS40Z9Iied5pUxLeo0yiHm/view?usp=sharing). It is an card image that you will write to your SD card.
4. Open Win32DiskImager. Insert your SD card and browse to the file that you downloaded.
5. Make sure that you backed up everything on the card. Click 'WRITE' and wait until the status bar finishes.
6. Remove the SD card from your computer and insert it into SLOT 2 of the EOS R6. Turn the camera on. Push the 'PLAY' icon and then push 'SET'. Wait until the RED LED stops flashing.
7. Remove the SD card from your camera and put it back into your computer. You should now have the rom dump files (boot00.bin, gang100.bin, and gang200.bin).
8.
DO NOT POST THE ROMS PUBICALLY. Send them to me in a private message.
Quote from: Lars Steenhoff on September 08, 2020, 06:53:13 PM
https://www.lensrentals.com/blog/2020/09/taking-apart-the-canon-r5-mirrorless-camera/
Teardown of the R5
I may be wrong but is there a yellow tape covering at least a small part of the UART port and therefore denying external access without disassembly?
This shouldn't be a big problem for people who have decided to remove the rubber.
I have a little bit of trouble with the concept: Let's make a hole in the back, add a rubber plug into it. So we can access the UART and don't have to remove the back. Now add a tape to the back to cover this UART.
Just to confuse the russians? Is it cold war time again? ;-)
Quote from: yourboylloyd on September 08, 2020, 07:12:52 PM
Yes you can help if you have firmware version 1.0.0. I'll give you some steps below on how to perform a ROM dump.
Do you need 1.0 for the R5 as well or has this already been dumped?
Canon Just released a Firmware V1.1.1 for R5 and R6
Be aware of possible lock down on my hack finding last Sunday.
Even if I think it will be a very fast answer to roll out a firmware in only 3 days, that's still a possibility.
At least, it may be able to do a file comparison between V1.1.0 et V1.1.1 to see what changed is any.
Quote from: Walter Schulz on September 08, 2020, 05:35:00 PM
No offence but would you mind recording a video following the steps shown in video provided by EOSHD?
https://drive.google.com/file/d/1VUOchC3jeSj9sUlN3IOK36qsiA5N0ysy/view?usp=sharing
It only works with a battery door hack or a dummy battery. I've tried doing this at least 20 times as shown on EOSHD.
Quote from: stillinsane on September 09, 2020, 08:28:54 AM
Do you need 1.0 for the R5 as well or has this already been dumped?
Yes I believe that would be helpful. I think we only dumped 1.1
Quote from: visionrouge.net on September 09, 2020, 10:24:34 AM
Canon Just released a Firmware V1.1.1 for R5 and R6
Be aware of possible lock down on my hack finding last Sunday.
Even if I think it will be a very fast answer to roll out a firmware in only 3 days, that's still a possibility.
At least, it may be able to do a file comparison between V1.1.0 et V1.1.1 to see what changed is any.
Interesting. Keep us updated
Are downgrades possible ? or are they blocked
-Obsolete-
Quote from: Lars Steenhoff on September 09, 2020, 10:52:15 AM
Are downgrades possible ? or are they blocked
There is nothing to downgrade to on the R6. If we had the firmware file for a previous version then maybe this hack (https://www.magiclantern.fm/forum/index.php?topic=24926.0) would work. It may actually work for the R5 since there are multiple firmwares available now.
I wouldn't risk it though. The R6 is a perfect camera for me right now (unless canon implements a better CLog).
Quote from: Lars Steenhoff on September 09, 2020, 10:52:15 AM
Are downgrades possible ? or are they blocked
As yourboylloyd wrote: For R6 it is not possible from within Canon's menu because there is no firmware file available for the version before.
For R5: Requires testing. I doubt they blocked all downgrade options but this is just my very personal opinion not based on actual facts.
Quote from: visionrouge.net on September 09, 2020, 10:24:34 AM
Canon Just released a Firmware V1.1.1 for R5 and R6
Be aware of possible lock down on my hack finding last Sunday.
Even if I think it will be a very fast answer to roll out a firmware in only 3 days, that's still a possibility.
At least, it may be able to do a file comparison between V1.1.0 et V1.1.1 to see what changed is any.
Thats the reason that I asked on the first post about this issue.
I just drew attention to a strange thing, in the video mode on the R6 you cannot transfer the setting to c1 c2 c3, but in the photo mode you can. Firmware 1.1.1. Owner of R5, could you please check if you can transfer video modes to C1, etc?
https://wordpress.lensrentals.com/blog/2020/09/investigating-the-canon-r5-heat-emission/
Another look from lensentals into the Canon R5 Heat Emission
https://www.cined.com/canon-interview-r5-and-r6-overheating-questions-answered/?fbclid=IwAR3Gcl1dvLQxcXxTcXdhSP5P2lYpAuctorK5X77ATTZXAaZeLePsOHIpfBY
From this interview with canon:
Holding a very warm object for an extended period has the potential to result in what is known as low temperature burns.
This explains the timers, the camera can handle much higher temperatures than are comfortable for the human body.
Put the camera on a tripod or use heat resistant gloves ad you will be fine :)
Quote from: yourboylloyd on September 09, 2020, 10:57:21 AM
The R6 is a perfect camera for me right now (unless canon implements a better CLog).
I have a few questions to you or anyone else who can comment on them. How does R6 4k video filmed in PR 422, 10-bits compare to 5D3 RAW video filmed at 14/12-bits lossless in terms of image quality? Have you made such comparisons or have you seen them on the net? What do you mean by "better C-log"? Is the current one not good enough? How about the filmic look - doesn't R6 video look too digital? Now that you have the R6, don't you miss ML RAW video?
Personally, I think that the R6 will become the "perfect camera" if one day we see ML on it but this is just me and my dreams.
I'm curious to find comparisons too. that's the only step stopping me to switch from
5D3 with MLRAW to R6
there are two kinds of video shooters today (with regard to the topic of raw):
those who love the capabilities and nearly infinite flexibility of working with raw, and those who hate it and get headaches from it.
the limitations of working with log footage will always be inferior to raw for the first category of shooter.
in the end it probably hinges on one's primary motivation. is it more about ease of use and/or quick turnaround time, or perhaps about achieving a desired (artistic) appearance/evocative effect?
the answer of course is entirely individual, so the chances are you already know for yourself :)
for me the quality of the pixels outweighs their number.
plus, i just love working with magic lantern. after all these years it just feels like home. i can't imagine a canon camera without it! ;)
If anyone is not seeing the reset happen on EOS R5/R6, try it a second time
https://www.eoshd.com/news/canon-eos-r5-8k-stress-test-1-no-problem-with-timer-reset-so-far/
Most of the time I find it takes two goes.
Maybe you have to pull the battery within a certain amount of time.
A nice reaction game to play in the middle of a shoot :D
Quote from: IDA_ML on September 11, 2020, 07:59:39 AM
I have a few questions to you or anyone else who can comment on them.
How does R6 4k video filmed in PR 422, 10-bits compare to 5D3 RAW video filmed at 14/12-bits lossless in terms of image quality? Have you made such comparisons or have you seen them on the net?
I working on a side by side test of this. But honestly, the 10bit on the R6 is pretty amazing. Of course RAW would be better, but it's still 10x better than regular h.264. I am used to grading ML footage in adobe camera raw so the workflows are drastically different. But it's way better to be able to edit the footage right out of camera.
And there is extremely good shadow recovery. I've been 4 stops under exposed and there is almost no noise when I bring the image back up to EV0. A huge one is that I can also adjust the white balance of the video in post pretty accurately with the little dropper tool and no quality degradation.
The R6 does not shoot in ProRes though. The R6 uses HEVC instead of Prores.
What do you mean by "better C-log"? Is the current one not good enough?
I've used Clog1 Clog 2 and Clog3 in the past on other cameras. Clog3 better uses the full dynamic range of the sensor. Here is an extreme example taken on clog1 on the R6:
(https://i.ibb.co/vsBCkzk/clog1-example.png) (https://ibb.co/q0nLp1p)
I've shot the sun and the ocean in clog1. Now obviously, the sun is going to be completely blown out regardless of what I film at. But in the clip, the highlights only go to about 80% of the highest color information. The shadows only go down to 10%. I call this "too flat" and this is an extreme example. Most of the time, the shadows and highlights are usually within 60% of each other in clog1. When using clog3, these numbers are spread a lot more on the spectrum. Shooting on the c300 mark 3 in clog3, there is NO POINT in shooting RAW via HDMI. Clog 3 is that powerful to me.
But I will say that it is good enough. I've actually never been able to manipulate footage to such quality so fast before.
How about the filmic look - doesn't R6 video look too digital?
It depends on what you mean. When think of "Filmic" look, I think of imperfections. Maybe a little softness on lenses, or maybe random grain. High contrast. Good dynamic range. And stuff like that. But then when I see shows like Breaking Bad that was shot 100% on film, I feel like that is super digital looking with amazing dynamic range. But it was shot on film.
There are a lot of ways to make digital look like film, and film look like digital. The Alexa's and RED's are known for there dynamic range and ability to push to make look like film. But nowadays, that dynamic range exists on basic cams like these. The Sigma FP can produce some amazing footage that can be converted to look like film. I truly believe that with some tinkering, one could make the R6 look like film.
The biggest downside is that the R6 also films in IPB mode though and not ALL-I (which lowers the quality by compression). It's not too noticeable to me, but I'm sure there will be artifacts if I were inches away from an 80" screen.
Now that you have the R6, don't you miss ML RAW video?
Actually not really (which is surprising me). I thought I would be switching back and forth between my 5D and the R6 on shoots, but you CANNOT beat the autofocus system on the R6. I was shooting a model on an EF 100mm f/2 lens and she was in moving around a lot. BUT SHE WAS IN FOCUS THE ENTIRE TIME! Every single frame, here eyes were sharp. The IBIS also was perfect for handholding 100mm. No matter how good Magic Lantern gets on the old cameras, it can't beat such features.
Of course being able to PLAYBACK the footage on set is also huge. The zebras are helpful too, just as helpful as the magic lantern zebras.
Personally, I think that the R6 will become the "perfect camera" if one day we see ML on it but this is just me and my dreams.
Me too. I mean honestly if they can find a way to implement RAW HD on this camera then I would be happy (RAW 4K probably isn't possible due to slow SD card rates). But there is RAW light that can probably handle it. Of course I'm sure MLV can handle it too. I couldn't imagine what you devs could do with a 300MB/s write speed. It would be 100% the perfect camera if it had ALL-I recording with Clog3. Right now it's at about a 95% to me. But for being $2,500 plus a cheap $50 EF adapter (which works perfectly btw) it's basically perfect to me. I'm probably going to be using this camera for the next 10 years comfortably. I'm actually impressed with Canon's new battery too. It def lasts longer then the regular LP-E6 batteries. The new battery even works for my 5D!
TLDR: I would basically call the R6's clog1 9.5bit footage (Not full 10bit if that makes sense). More than double the dynamic range of regular h264, but still not using the camera's full capabilities. The autofocus and ibis are to die for though. I never realized how much I needed autofocus. I can properly look at the footage and see things that shouldn't be there instead of worrying about racking focus at the right time.
Edit: Something that I want to try is making a video in 20fps photo burst mode. The photos are 16bit (a bit overkill but sweet) but still 4fps too slow to make the smooth 24fps. Maybe I can shoot a music video and slow the song down to 0.83x, then interpret the footage as 24fps. Open gate (4:3), 5.4K, and 16bit! I can't imagine what that would look like.
Yourboylloyd,
Thank you so much for taking the time to provide this detailed and very useful information. I agree that perfect focus and IBIS are much more important for the final result than a slight quality degradation which is the price to pay for not filming in RAW.
A short comment on your intention to film a RAW video at 20 fps. You shouldn't worry about the missing 4 fps since Resolve does a hell of a job compensating for them using the optical flow algorithm. Please check if there is some dead time between the shots because in that case, you may end up with a choppy video. Also, as far as I understand, you lose the tracking AF at 20 fps.
Okay so I learned something. I tried to compare the R6 in 1920x1080 mode to the 5D2 1880x1268, but the 5D2 footage was coming out sharper (when I nailed the focus that is). Here is the example video stills all shot on Sigma 35mm 1.4 @f/2:
(https://i.ibb.co/S5CG0WF/r6hd-vs-5d2-hd.jpg)
Fullsized image. (https://i.ibb.co/NtBbpQc/r6hd-vs-5d2-hd.jpg) (Note that accidently captioned 1880p, but it's actually 1880width)
The R6 produces random artifacts in 1080p mode for some reason. This is kind of a bummer to me. I don't know what that is but it happens every few frames. I didn't apply any sharpening or anything. I can confirm that this doesn't happen on the R6 in 4K mode though.
(https://i.ibb.co/P1CJpyD/zoom-artifacts.jpg)
I can't believe I'm saying this but basically the 5D2 RAW is sharper than the R6 in 1080p mode. And I'm not sure what's going on with the artifacts on the R6.
Otherwise: I'm not a hugely master colorist, but I do feel like the color ranges and dynamic range is roughly the same with a shot that has been exposed correctly. Will do more tests and report back soon
Could be compression artifacts. Looks similar to JPEG quantisation. RAW wouldn't have those.
Interesting. Try to compare 3k or 3,5k raw with 4k from R6. Could be surprising.
Basiquely, a camera like R6 with autofocus and ibis should be usefull for low budget corporate film, interviews.. but not an avantage for an artistic short film where magic lantern should be still a good choice.
https://petapixel.com/2020/09/12/canon-we-dont-cripple-cameras-idea-is-conspiracy-theory/
Memory map for R5/R6 (see also for DIGIC 7 (https://www.magiclantern.fm/forum/index.php?topic=19737.msg212603#msg212603) and DIGIC 8 (https://www.magiclantern.fm/forum/index.php?topic=22770.msg212090#msg212090)):
00001000-00001FFF -> 00000000-00000FFF (-1000) O:NCACH I:WB,WA P:RW [ CPU0 only ]
00001000-00001FFF -> 00001000-00001FFF ( +0) O:NCACH I:WB,WA P:RW [ CPU1 only ]
00002000-3FFFFFFF -> 00001000-3FFFFFFF ( +0) O:NCACH I:WB,WA P:RW [ cacheable RAM - only the first GiB ]
40000000-BEFFFFFF -> 40000000-BEFFFFFF ( +0) O:NCACH I:NCACH P:RW [ uncacheable RAM - 2 GiB ]
BF000000-DEFFFFFF -> BF000000-DEFFFFFF ( +0) Device P:RW XN [ MMIO area ]
DF000000-DFFFFFFF -> DF000000-DFFFFFFF ( +0) O:NCACH I:WB,WA P:RW [ TCM? ]
E0000000-E7FFFFFF -> E0000000-E7FFFFFF ( +0) O:WB,WA I:WB,WA P:R [ main ROM ]
E8000000-EFFFFFFF -> E8000000-EFFFFFFF ( +0) Strongly-ordered P:RW XN [ ? ]
F0000000-F7FFFFFF -> F0000000-F7FFFFFF ( +0) O:WB,WA I:WB,WA P:R [ secondary ROM ]
F8000000-FFFFFFFF -> F8000000-FFFFFFFF ( +0) Strongly-ordered P:R XN [ ? ]
Created with this script (https://a1ex.magiclantern.fm/bleeding-edge/R5/v7mmap.py) and annotated manually.
Quote from: names_are_hard on September 12, 2020, 04:38:32 AM
Could be compression artifacts. Looks similar to JPEG quantisation. RAW wouldn't have those.
Mostly shooting commercials on film
But also have shot with Alexa (this is around where the 5d3 with ml is)
Hi camera hackers,
Could you please send me a craw file from R6 ?
Optionnally with dust removal option enabled ?
it is to improve my work at:
https://github.com/lclevy/canon_cr3
Kind regards,
Laurent
You can find some raw files from the R6 here:
https://www.dpreview.com/sample-galleries/6671206782/canon-eos-r6-sample-gallery/8454525047
Quote from: lorenzo353 on September 17, 2020, 11:05:42 PM
Could you please send me a craw file from R6 ?
I'll send two :) (https://drive.google.com/drive/folders/131JhhH58z_PJHD96N8XnMnCjPkTkCkbA?usp=sharing)
Quote from: Lars Steenhoff on September 18, 2020, 11:54:09 PM
You can find some raw files from the R6 here:
https://www.dpreview.com/sample-galleries/6671206782/canon-eos-r6-sample-gallery/8454525047
Thank you, Lars, but I need CRAW (compact raw) files, please
Quote from: yourboylloyd on September 19, 2020, 01:43:41 AM
I'll send two :) (https://drive.google.com/drive/folders/131JhhH58z_PJHD96N8XnMnCjPkTkCkbA?usp=sharing)
Thank you!
Ohhhhh sorry. Didn't know that there was a difference. I'll take some in a few
did anyone noticed that change in the firmware 1.1.1 of the R6
https://www.canon-europe.com/support/consumer_products/products/cameras/digital_slr/eos-r6.html?type=firmware&firmwaredetailid=tcm:13-2011538&os=macos%2010.15%20%28catalina%29&language=en (https://www.canon-europe.com/support/consumer_products/products/cameras/digital_slr/eos-r6.html?type=firmware&firmwaredetailid=tcm:13-2011538&os=macos%2010.15%20%28catalina%29&language=en)
(https://i.imgur.com/KOjivlO.png)
is it related to the "time hack" ?
seems like a way from canon to prevent the date change timer reset
Has anyone any facts or are we going EOSHD here?
No facts just assumtions based on that firmware discription
Quote from: Lars Steenhoff on September 30, 2020, 03:58:07 PM
seems like a way from canon to prevent the date change timer reset
It's been reported the timer reset hack is still working with firmware 1.1.1
Thanks, glad to see my assumption was wrong
great ! Sorry to have sounded the alarm :)
any 5d3 w/danne build VS R5 raw videos in the wild? or would anybody be able to make one? sorry if this has been discussed already.
I'm working on an R6 10bit vs 5D2 10bit video. Probably not the same but close enough right?
Quote from: yourboylloyd on October 05, 2020, 03:39:58 PM
I'm working on an R6 10bit vs 5D2 10bit video. Probably not the same but close enough right?
Not close enough for me :) you know why :)
The quality of R6 is outstanding ofcourse
You two should do a collab together. This raw postprocessing and quality at shooting is also outstanding. I post his forumthread here: https://www.magiclantern.fm/forum/index.php?topic=25312.0
In case some are interested. https://blog.yifangu.com/2020/10/09/canon-eos-r5-thermal-mod/
Hi,
could you please send me craw files ?
Lorenzo
Quote from: yourboylloyd on September 21, 2020, 12:24:45 AM
Ohhhhh sorry. Didn't know that there was a difference. I'll take some in a few
Quote from: lorenzo353 on October 12, 2020, 11:57:11 PM
could you please send me craw files ?
Wowwww I swore I did that already. Sorry. Check your PM
I've got R5 craw files. If anyone needs them, let me know
Sent from my Pixel 4 XL using Tapatalk
Crosspost from https://www.magiclantern.fm/forum/index.php?topic=22770.msg233318#msg233318 (https://www.magiclantern.fm/forum/index.php?topic=22770.msg233318#msg233318):
'Get R6 LED base
private sub save_led_base(fileName)
RemoveFile(fileName)
f = OpenFileCREAT(fileName)
CloseFile(f)
f = OpenFileWR(fileName)
pLedBase = 0x4F54
WriteFileString(f, "LED base 1: [0x%08X]: 0x%08X\n", pLedBase, *pLedBase)
pLedBase = 0x4F5C
WriteFileString(f, "LED base 2: [0x%08X]: 0x%08X\n", pLedBase, *pLedBase)
CloseFile(f)
end sub
private sub Initialize()
save_led_base("B:/LED_BASE.TXT")
end sub
Could someone with a R6 execute this and tell me the result?
Update: yourboylloyd did run this on his R6 and got the following result:
[0x01A14B24] LED 0: 0xD22390C2
[0x01A14B48] LED 1: 0xD2239000
[0x01A14B6C] LED 2: 0xD22393FC
[0x01A14B90] LED 3: 0xD2239000
[0x01A14BB4] LED 4: 0xD2239001
[0x01A14BD8] LED 5: 0xD2238F00
[0x01A14BFC] LED 6: 0xD223900B
[0x01A14C20] LED 7: 0xD2239037
[0x01A14C44] LED 8: 0xD2239000
[0x01A14C68] LED 9: 0xD2239001
[0x01A14C8C] LED 10: 0x30218F00
[0x01A14CB0] LED 11: 0xD223900B
[0x01A14CD4] LED 12: 0xD2239037
[0x01A14CF8] LED 13: 0xD2239000
[0x01A14D1C] LED 14: 0xD2239001
[0x01A14D40] LED 15: 0xD2238700
[0x01A14D64] LED 16: 0xD223900B
[0x01A14D88] LED 17: 0xD2239037
[0x01A14DAC] LED 18: 0xD2239000
[0x01A14DD0] LED 19: 0xD2239001
[0x01A14DF4] LED 20: 0xD2238F00
[0x01A14E18] LED 21: 0xD223900B
[0x01A14E3C] LED 22: 0xD2239037
[0x01A14E60] LED 23: 0xD2239000
[0x01A14E84] LED 24: 0xD2239001
[0x01A14EA8] LED 25: 0xD2238F00
[0x01A14ECC] LED 26: 0xD223900B
[0x01A14EF0] LED 27: 0xD2239037
[0x01A14F14] LED 28: 0xD2239000
[0x01A14F38] LED 29: 0xD2239001
[0x01A14F5C] LED 30: 0xD2238F00
[0x01A14F80] LED 31: 0xB24F797D
[0x01A14FA4] LED 32: 0xD2238DFF
[0x01A14FC8] LED 33: 0xD3C4DFA0
[0x01A14FEC] LED 34: 0xD2239000
[0x01A15010] LED 35: 0xB24F797D
[0x01A15034] LED 36: 0xD2238FFF
[0x01A15058] LED 37: 0xD3C4E030
[0x01A1507C] LED 38: 0xD2239000
[0x01A150A0] LED 39: 0xB24F797D
[0x01A150C4] LED 40: 0xD2238FDD
[0x01A150E8] LED 41: 0xD3C4E0C0
[0x01A1510C] LED 42: 0xD2239000
[0x01A15130] LED 43: 0xB24F797D
[0x01A15154] LED 44: 0xD0238BDF
[0x01A15178] LED 45: 0xD3C4E150
[0x01A1519C] LED 46: 0xD2239000
[0x01A151C0] LED 47: 0xB24F797D
[0x01A151E4] LED 48: 0xD0238FFF
[0x01A15208] LED 49: 0xD3C4E1E0
[0x01A1522C] LED 50: 0xD2239000
[0x01A15250] LED 51: 0xB24F797D
[0x01A15274] LED 52: 0xD2238FFF
[0x01A15298] LED 53: 0xD3C4E270
[0x01A152BC] LED 54: 0xD2239000
[0x01A152E0] LED 55: 0xB24F797D
Card LED address is probably 0xD22390C2 on R6 but I am a bit confused why there are 56 possible LEDs...
Crosspost from https://www.magiclantern.fm/forum/index.php?topic=22770.msg233556#msg233556:
'Get R6 Interrupt Vector Table
dim pIvt_table_1 = 0x2efd8
dim vector1_len = 0x280
dim pIvt_table_2 = 0x311dc
dim vector2_len = 0x40
private sub write_table(hFile, pVectorTable, startVector, numElements)
isrVector = startVector
do while isrVector < numElements
ppIrqName = pVectorTable + isrVector * 4
WriteFileString(hFile, "0x%03X: %s\n", isrVector, *ppIrqName)
isrVector = isrVector + 1
loop
end sub
private sub save_ivt(fileName)
RemoveFile(fileName)
hFile = OpenFileCREAT(fileName)
CloseFile(hFile)
hFile = OpenFileWR(fileName)
write_table(hFile, pIvt_table_1, 0, vector1_len)
write_table(hFile, pIvt_table_2, vector1_len, vector2_len)
CloseFile(hFile)
end sub
private sub Initialize()
save_ivt("B:/R6_IVT.TXT")
end sub
Could someone with a R6 execute this and tell me the result?
update: again yourboylloyd did run this on his R6 (thanks alot!) and got the following result:
0x000: -noise-
0x001: EDOMAIN_EDMAC_1_WR_M1
0x002: EDOMAIN_EDMAC_6_WR_SS7
0x003: EDOMAIN_EDMAC_3_RD_S1_A
0x004: EDOMAIN_VITON1
0x005: (reserved)
0x006: (reserved)
0x007: CPROC_14
0x008: TMU_INT_SWA
0x009: TMU_INT_OCCH0SP
0x00A: INTC_XINT_0
0x00B: TCU_T0OUT
0x00C: POSTMAN_RCVINT0
0x00D: POSTMAN_FIFOINT0
0x00E: MARIUS_TIMER_OC0_INT
0x00F: MARIUS_TIMER_IC0_INT
0x010: EDOMAIN_SYNGEN_1
0x011: EDOMAIN_EDMAC_1_WR_S0
0x012: EDOMAIN_EDMAC_6_WR_SS8
0x013: EDOMAIN_EDMAC_3_RD_L0_B
0x014: EDOMAIN_VITON2
0x015: (reserved)
0x016: (reserved)
0x017: CPROC_15
0x018: TMU_INT_SWB
0x019: TMU_INT_OCCH0EP
0x01A: INTC_XINT_1
0x01B: TCU_T1OUT
0x01C: POSTMAN_RCVINT1
0x01D: POSTMAN_FIFOINT1
0x01E: MARIUS_TIMER_OC1_INT
0x01F: MARIUS_TIMER_IC1_INT
0x020: EDOMAIN_SYNGEN_2
0x021: EDOMAIN_EDMAC_1_WR_S1
0x022: EDOMAIN_EDMAC_6_WR_SS9
0x023: EDOMAIN_EDMAC_3_RD_L1_B
0x024: EDOMAIN_AFFINE_OVR_ERR
0x025: (reserved)
0x026: (reserved)
0x027: SYNC_IRQ_LSS1
0x028: TMU_INT_OCALL
0x029: TMU_INT_OCCH1SP
0x02A: INTC_XINT_2
0x02B: TCU_T2OUT
0x02C: POSTMAN_RCVINT2
0x02D: POSTMAN_FIFOINT2
0x02E: MARIUS_TIMER_OC2_INT
0x02F: MARIUS_TIMER_IC2_INT
0x030: EDOMAIN_SYNGEN_3
0x031: EDOMAIN_EDMAC_1_WR_S2
0x032: EDOMAIN_EDMAC_7_WR_S0
0x033: EDOMAIN_EDMAC_3_RD_S0_B
0x034: EDOMAIN_SARIDON
0x035: (reserved)
0x036: (reserved)
0x037: SYNC_IRQ_LSS1_ST1
0x038: TMU_INT_PULGENCEI
0x039: TMU_INT_OCCH1EP
0x03A: INTC_XINT_3
0x03B: TCU_T3OUT
0x03C: POSTMAN_RCVINT3
0x03D: POSTMAN_FIFOINT3
0x03E: MARIUS_TIMER_OC3_INT
0x03F: MARIUS_TIMER_IC3_INT
0x040: EDOMAIN_SYNGEN_4
0x041: EDOMAIN_EDMAC_1_WR_S3
0x042: EDOMAIN_EDMAC_7_WR_S1
0x043: EDOMAIN_EDMAC_3_RD_S1_B
0x044: EDOMAIN_MESSI
0x045: (reserved)
0x046: (reserved)
0x047: SYNC_IRQ_LSS2
0x048: TMU_INT_ICAPCEI
0x049: TMU_INT_OCCH2SP
0x04A: INTC_XINT_4
0x04B: TCU_T4OUT
0x04C: POSTMAN_RCVINT4
0x04D: POSTMAN_FIFOINT4
0x04E: MARIUS_TIMER_OC4_INT
0x04F: MARIUS_TIMER_IC4_INT
0x050: EDOMAIN_SYNGEN_FRM
0x051: EDOMAIN_EDMAC_1_WR_S4
0x052: EDOMAIN_EDMAC_7_WR_SS0
0x053: EDOMAIN_EDMAC_5_RD_L0
0x054: EDOMAIN_DURAN
0x055: (reserved)
0x056: (reserved)
0x057: SYNC_IRQ_LSS2_ST1
0x058: CPROC_0
0x059: TMU_INT_OCCH2EP
0x05A: INTC_XINT_5
0x05B: TCU_T5OUT
0x05C: POSTMAN_RCVINT5
0x05D: POSTMAN_FIFOINT5
0x05E: MARIUS_TIMER_OC5_INT
0x05F: MARIUS_TIMER_IC5_INT
0x060: EDOMAIN_SYNGEN_1_A
0x061: EDOMAIN_EDMAC_1_WR_SS0
0x062: EDOMAIN_EDMAC_7_CAP_WR_SS0
0x063: EDOMAIN_EDMAC_5_RD_M0
0x064: EDOMAIN_DANCING_FEN
0x065: (reserved)
0x066: (reserved)
0x067: SYNC_IRQ_INTVI1
0x068: CPROC_1
0x069: TMU_INT_OCCH3SP
0x06A: INTC_XINT_6
0x06B: TCU_IPCOUT4
0x06C: POSTMAN_RCVINT6
0x06D: POSTMAN_FIFOINT6
0x06E: MARIUS_TIMER_OC6_INT
0x06F: MARIUS_TIMER_IC6_INT
0x070: EDOMAIN_SYNGEN_2_A
0x071: EDOMAIN_EDMAC_1_WR_SS1
0x072: EDOMAIN_EDMAC_7_CAP_WR_SS1
0x073: EDOMAIN_EDMAC_5_RD_M1
0x074: EDOMAIN_DANCING_SURF
0x075: (reserved)
0x076: (reserved)
0x077: SYNC_IRQ_VI1_SET_1
0x078: CPROC_2
0x079: TMU_INT_OCCH3EP
0x07A: INTC_XINT_7
0x07B: TCU_T4F_INT
0x07C: POSTMAN_RCVINT7
0x07D: POSTMAN_FIFOINT7
0x07E: MARIUS_TIMER_OC7_INT
0x07F: MARIUS_TIMER_IC7_INT
0x080: EDOMAIN_SYNGEN_3_A
0x081: EDOMAIN_EDMAC_1_WR_SS2
0x082: EDOMAIN_EDMAC_7_CAP_WR_SS2
0x083: EDOMAIN_EDMAC_5_RD_S0
0x084: EDOMAIN_DANCING_RACI
0x085: FDOMAIN_0
0x086: SYNC_IRQ_INTB60V
0x087: SYNC_IRQ_VI1_SET_2
0x088: CPROC_3
0x089: TMU_INT_OCCH4SP
0x08A: INTC_XINT_8
0x08B: TCU_IPCOUT5
0x08C: POSTMAN_DIRECTINT0
0x08D: POSTMAN_SEMAPHORE0
0x08E: MARIUS_TIMER_ICOC_OC0INT
0x08F: MARIUS_TIMER_ICOC_IC0INT
0x090: EDOMAIN_SYNGEN_4_A
0x091: EDOMAIN_EDMAC_1_WR_SS3
0x092: EDOMAIN_EDMAC_0_OPERA_WR
0x093: EDOMAIN_EDMAC_5_RD_S1
0x094: EDOMAIN_KOALA_WR0
0x095: FDOMAIN_1
0x096: SYNC_IRQ_INTB59V
0x097: SYNC_IRQ_VI1_SET_3
0x098: CPROC_4
0x099: TMU_INT_OCCH4EP
0x09A: INTC_XINT_9
0x09B: TCU_T5F_INT
0x09C: POSTMAN_DIRECTINT1
0x09D: POSTMAN_SEMAPHORE1
0x09E: MARIUS_TIMER_ICOC_OC1INT
0x09F: MARIUS_TIMER_ICOC_IC1INT
0x0A0: EDOMAIN_SYNGEN_FRM_A
0x0A1: EDOMAIN_EDMAC_1_WR_SS4
0x0A2: EDOMAIN_EDMAC_6_DAN_WR
0x0A3: EDOMAIN_EDMAC_5_RD_S2
0x0A4: EDOMAIN_KOALA_WR1
0x0A5: FDOMAIN_2
0x0A6: SYNC_IRQ_INTB50V
0x0A7: SYNC_IRQ_INTVI2
0x0A8: CPROC_5
0x0A9: TMU_INT_OCCH5SP
0x0AA: INTC_XINT_10
0x0AB: APROC_0
0x0AC: POSTMAN_DIRECTINT2
0x0AD: POSTMAN_SEMAPHORE2
0x0AE: OMAR_TIMER_OC0_INT
0x0AF: OMAR_TIMER_IC0_INT
0x0B0: EDOMAIN_SYNGEN_1_B
0x0B1: EDOMAIN_EDMAC_2_WR_L0_A
0x0B2: EDOMAIN_EDMAC_1_RD_L0
0x0B3: EDOMAIN_EDMAC_6_RD_S0
0x0B4: EDOMAIN_KOALA_WR2
0x0B5: FDOMAIN_3
0x0B6: SYNC_IRQ_INTB49V
0x0B7: SYNC_IRQ_VI2_SET_1
0x0B8: CPROC_6
0x0B9: TMU_INT_OCCH5EP
0x0BA: INTC_XINT_11
0x0BB: APROC_1
0x0BC: POSTMAN_DIRECTINT3
0x0BD: POSTMAN_SEMAPHORE3
0x0BE: OMAR_TIMER_OC1_INT
0x0BF: OMAR_TIMER_IC1_INT
0x0C0: EDOMAIN_SYNGEN_2_B
0x0C1: EDOMAIN_EDMAC_2_WR_L1_A
0x0C2: EDOMAIN_EDMAC_1_RD_L1
0x0C3: EDOMAIN_EDMAC_6_RD_S1
0x0C4: EDOMAIN_KOALA_RD0
0x0C5: FDOMAIN_4
0x0C6: SYNC_IRQ_INTL60V1
0x0C7: SYNC_IRQ_VI2_SET_2
0x0C8: CPROC_7
0x0C9: TMU_INT_ICAPCH0
0x0CA: INTC_XINT_12
0x0CB: APROC_2
0x0CC: POSTMAN_DIRECTINT4
0x0CD: POSTMAN_FIFO_ERR0
0x0CE: OMAR_TIMER_OC2_INT
0x0CF: OMAR_TIMER_IC2_INT
0x0D0: EDOMAIN_SYNGEN_3_B
0x0D1: EDOMAIN_EDMAC_2_WR_S0_A
0x0D2: EDOMAIN_EDMAC_1_RD_L2
0x0D3: EDOMAIN_EDMAC_6_RD_S2
0x0D4: EDOMAIN_KOALA_RD1
0x0D5: FDOMAIN_5
0x0D6: SYNC_IRQ_INTL60V1_ST1
0x0D7: SYNC_IRQ_VI2_SET_3
0x0D8: CPROC_8
0x0D9: TMU_INT_ICAPCH1
0x0DA: INTC_XINT_13
0x0DB: APROC_3
0x0DC: POSTMAN_DIRECTINT5
0x0DD: UART0_RX_INTREQRX
0x0DE: OMAR_TIMER_OC3_INT
0x0DF: OMAR_TIMER_IC3_INT
0x0E0: EDOMAIN_SYNGEN_4_B
0x0E1: EDOMAIN_EDMAC_2_WR_L0_B
0x0E2: EDOMAIN_EDMAC_1_RD_M0
0x0E3: EDOMAIN_EDMAC_6_RD_S3
0x0E4: EDOMAIN_KOALA_RD2
0x0E5: FDOMAIN_6
0x0E6: SYNC_IRQ_INTL60V2
0x0E7: SYNC_IRQ_INTVI3
0x0E8: CPROC_9
0x0E9: TMU_INT_ICAPCH2
0x0EA: INTC_XINT_14
0x0EB: APROC_4
0x0EC: POSTMAN_DIRECTINT6
0x0ED: UART0_TX_INTREQTX
0x0EE: OMAR_TIMER_OC4_INT
0x0EF: OMAR_TIMER_IC4_INT
0x0F0: EDOMAIN_SYNGEN_FRM_B
0x0F1: EDOMAIN_EDMAC_2_WR_L1_B
0x0F2: EDOMAIN_EDMAC_1_RD_S0
0x0F3: EDOMAIN_EDMAC_6_RD_S4
0x0F4: EDOMAIN_COMBAT_INTEG_1
0x0F5: FDOMAIN_7
0x0F6: SYNC_IRQ_INTL60V2_ST1
0x0F7: SYNC_IRQ_VI3_SET_1
0x0F8: CPROC_10
0x0F9: TMU_INT_ICAPCH3
0x0FA: INTC_XINT_15
0x0FB: APROC_5
0x0FC: POSTMAN_DIRECTINT7
0x0FD: UART1_RX_INTREQRX
0x0FE: OMAR_TIMER_OC5_INT
0x0FF: OMAR_TIMER_IC5_INT
0x100: EDOMAIN_HEAD_ERR
0x101: EDOMAIN_EDMAC_2_WR_S0_B
0x102: EDOMAIN_EDMAC_1_RD_S1
0x103: EDOMAIN_EDMAC_6_RD_S5
0x104: EDOMAIN_COMBAT_BLOCK_1
0x105: FDOMAIN_8
0x106: SYNC_IRQ_INTL59V1
0x107: SYNC_IRQ_VI3_SET_2
0x108: CPROC_11
0x109: TMU_INT_ICAPCH4
0x10A: INTC_XINT_16
0x10B: APROC_6
0x10C: CCLIME_INT_SODA
0x10D: UART1_TX_INTREQTX
0x10E: OMAR_TIMER_OC6_INT
0x10F: OMAR_TIMER_IC6_INT
0x110: EDOMAIN_ATOMIC_ERR
0x111: EDOMAIN_EDMAC_3_WR_L0_A
0x112: EDOMAIN_EDMAC_1_RD_SS0
0x113: EDOMAIN_EDMAC_6_RD_S6
0x114: EDOMAIN_COMBAT_INTEG_7
0x115: (reserved)
0x116: SYNC_IRQ_INTL59V1_ST1
0x117: SYNC_IRQ_VI3_SET_3
0x118: CPROC_12
0x119: TMU_INT_ICAPCH5
0x11A: INTC_XINT_17
0x11B: APROC_7
0x11C: CCLIME_INT_TM2MD_RDMA
0x11D: UART2_RX_INTREQRX
0x11E: OMAR_TIMER_OC7_INT
0x11F: OMAR_TIMER_IC7_INT
0x120: EDOMAIN_HEAD_ERR2
0x121: EDOMAIN_EDMAC_3_WR_S0_A
0x122: EDOMAIN_EDMAC_1_RD_SS1
0x123: EDOMAIN_EDMAC_6_RD_S7
0x124: EDOMAIN_COMBAT_BLOCK_7
0x125: (reserved)
0x126: SYNC_IRQ_INTL59V2
0x127: SYNC_IRQ_INTVI4
0x128: CPROC_13
0x129: TMU_INT_ICAPCH6
0x12A: INTC_XINT_18
0x12B: APROC_8
0x12C: CCLIME_INT_TM2MD_WDMA
0x12D: UART2_TX_INTREQTX
0x12E: OMAR_TIMER_ICOC_OC0INT
0x12F: OMAR_TIMER_ICOC_IC0INT
0x130: EDOMAIN_HEAD_ERR3
0x131: EDOMAIN_EDMAC_3_WR_S1_A
0x132: EDOMAIN_EDMAC_1_RD_SS2
0x133: EDOMAIN_EDMAC_6_RD_S8
0x134: EDOMAIN_WEABER1
0x135: ORCA_A_0
0x136: SYNC_IRQ_INTL59V2_ST1
0x137: SYNC_IRQ_VI4_SET_1
0x138: CPROC_16
0x139: TMU_INT_ICAPCH7
0x13A: INTC_XINT_19
0x13B: APROC_9
0x13C: CCLIME_INT_TSUMXD_RDMAC
0x13D: PCIE_IRQ_PCIE0
0x13E: OMAR_TIMER_ICOC_OC1INT
0x13F: OMAR_TIMER_ICOC_IC1INT
0x140: EDOMAIN_SAP1
0x141: EDOMAIN_EDMAC_3_WR_L0_B
0x142: EDOMAIN_EDMAC_1_RD_SS3
0x143: EDOMAIN_EDMAC_6_RD_SS0
0x144: EDOMAIN_WEABER2
0x145: ORCA_A_1
0x146: SYNC_IRQ_INTL50V1
0x147: SYNC_IRQ_VI4_SET_2
0x148: CPROC_17
0x149: TMU_INT_ICAPCH8
0x14A: INTC_XINT_20
0x14B: (reserved)
0x14C: CCLIME_INT_TSUMXD_W0DMA
0x14D: PCIE_IRQ_PCIE1
0x14E: REM_REM_INT
0x14F: ZICO_TIMER_IRQ
0x150: EDOMAIN_SAP2
0x151: EDOMAIN_EDMAC_3_WR_S0_B
0x152: EDOMAIN_EDMAC_1_RD_SS4
0x153: EDOMAIN_EDMAC_6_RD_SS1
0x154: EDOMAIN_HISTORY
0x155: ORCA_A_2
0x156: SYNC_IRQ_INTL50V1_ST1
0x157: SYNC_IRQ_VI4_SET_3
0x158: CPROC_18
0x159: TMU_INT_ICAPCH9
0x15A: INTC_XINT_21
0x15B: (reserved)
0x15C: CCLIME_INT_TSUMXD_W1DMA
0x15D: PCIE_IRQ_PCIE2
0x15E: SDDOMAIN_SDCON0
0x15F: HDMAC0_INTRREQ1
0x160: EDOMAIN_LIP
0x161: EDOMAIN_EDMAC_3_WR_S1_B
0x162: EDOMAIN_EDMAC_1_RD_SS5
0x163: EDOMAIN_EDMAC_6_RD_SS2
0x164: EDOMAIN_HISTORY2_1
0x165: ORCA_A_3
0x166: SYNC_IRQ_INTL50V2
0x167: SYNC_IRQ_INTVI4B
0x168: (reserved)
0x169: TMU_INT_ICAPCH10
0x16A: INTC_XINT_22
0x16B: (reserved)
0x16C: CCLIME_INT_CPU_SLEEP
0x16D: PCIE_IRQ_PCIE3
0x16E: SDDOMAIN_TDMAC0
0x16F: HDMAC0_INTRREQ2
0x170: EDOMAIN_SANTA1
0x171: EDOMAIN_EDMAC_5_WR_M0
0x172: EDOMAIN_EDMAC_1_RD_SS6
0x173: EDOMAIN_EDMAC_6_RD_SS3
0x174: EDOMAIN_HISTORY2_2
0x175: ORCA_A_4
0x176: SYNC_IRQ_INTL50V2_ST1
0x177: SYNC_IRQ_VI4B_SET_1
0x178: (reserved)
0x179: TMU_INT_ICAPCH11
0x17A: INTC_XINT_23
0x17B: (reserved)
0x17C: CCLIME_INT_OTHERS
0x17D: PCIE_IRQ_PCIE4
0x17E: SDDOMAIN_SDCON1
0x17F: HDMAC0_INTRREQ3
0x180: EDOMAIN_YAWARA
0x181: EDOMAIN_EDMAC_5_WR_S0
0x182: EDOMAIN_EDMAC_2_RD_L0_A
0x183: EDOMAIN_EDMAC_6_RD_SS4
0x184: EDOMAIN_HISTORY2_3
0x185: ORCA_A_5
0x186: SYNC_IRQ_INTLSSDV1
0x187: SYNC_IRQ_VI4B_SET_2
0x188: (reserved)
0x189: TMU_INT_SWA_ONLY
0x18A: INTC_XINT_24
0x18B: HERMES_SITTER
0x18C: CCLIME_INT_UART1_RX
0x18D: PCIE_IRQ_PCIE5
0x18E: SDDOMAIN_TDMAC1
0x18F: HDMAC0_INTRREQ4
0x190: EDOMAIN_OPERA_OPEKICK0
0x191: EDOMAIN_EDMAC_5_WR_S1
0x192: EDOMAIN_EDMAC_2_RD_L1_A
0x193: EDOMAIN_EDMAC_6_RD_SS5
0x194: EDOMAIN_HISTORY2_4
0x195: ORCA_A_6
0x196: SYNC_IRQ_INTLSSDV1_ST1
0x197: SYNC_IRQ_VI4B_SET_3
0x198: SYNC_IRQ_VI6_SET_3
0x199: TMU_INT_SWB_ONLY
0x19A: INTC_XINT_25
0x19B: HERMES_SWEET
0x19C: CCLIME_INT_UART1_TX
0x19D: USB_INT_TENG
0x19E: SDDOMAIN_SDCON2
0x19F: HDMAC0_INTRREQ5
0x1A0: EDOMAIN_OPERA_OPEKICK1
0x1A1: EDOMAIN_EDMAC_5_WR_S2
0x1A2: EDOMAIN_EDMAC_2_RD_S0_A
0x1A3: EDOMAIN_EDMAC_6_RD_SS6
0x1A4: EDOMAIN_BIKING
0x1A5: ORCA_A_7
0x1A6: SYNC_IRQ_INTLSSDV2
0x1A7: SYNC_IRQ_INTVI5
0x1A8: SYNC_IRQ_INTVI7
0x1A9: TMU_INT_SWC_ONLY
0x1AA: INTC_XINT_26
0x1AB: HERMES_SWAN0
0x1AC: CCLIME_INT_TSUM_SD_SDCON
0x1AD: DSI0_IRQ_DSI0
0x1AE: SDDOMAIN_TDMAC2
0x1AF: HDMAC0_INTRREQ6
0x1B0: EDOMAIN_OPERA_OPEKICK2
0x1B1: EDOMAIN_EDMAC_6_WR_S0
0x1B2: EDOMAIN_EDMAC_2_RD_S1_A
0x1B3: EDOMAIN_EDMAC_6_RD_SS7
0x1B4: EDOMAIN_CAPTAIN
0x1B5: ORCA_A_8
0x1B6: SYNC_IRQ_INTLSSDV2_ST1
0x1B7: SYNC_IRQ_INTVI6
0x1B8: SYNC_IRQ_VI7_SET_1
0x1B9: TMU_INT_SWD_ONLY
0x1BA: INTC_XINT_27
0x1BB: HERMES_SWAN1
0x1BC: CCLIME_INT_TSUM_SD_DMA
0x1BD: DSI1_IRQ_DSI1
0x1BE: DMA330_0
0x1BF: HDMAC0_INTRREQ7
0x1C0: EDOMAIN_OPERA_OPEKICK3
0x1C1: EDOMAIN_EDMAC_6_WR_S1
0x1C2: EDOMAIN_EDMAC_2_RD_S2_A
0x1C3: EDOMAIN_EDMAC_6_RD_SS8
0x1C4: EDOMAIN_COTTON
0x1C5: ORCA_A_9
0x1C6: SYNC_IRQ_INTP
0x1C7: SYNC_IRQ_VI6_SET_1
0x1C8: SYNC_IRQ_VI7_SET_2
0x1C9: (reserved)
0x1CA: INTC_IRQ_SOFT_OUT
0x1CB: HERMES_DUAL_CTRL
0x1CC: CCLIME_INT_CITRON_CORE
0x1CD: HDMI0_0
0x1CE: DMA330_1
0x1CF: MDOMAIN_0
0x1D0: EDOMAIN_OPERA_OPEKICK4
0x1D1: EDOMAIN_EDMAC_6_WR_S2
0x1D2: EDOMAIN_EDMAC_2_RD_S3_A
0x1D3: EDOMAIN_EDMAC_7_RD_S0
0x1D4: EDOMAIN_OPERA0
0x1D5: ORCA_A_10
0x1D6: SYNC_IRQ_INTP_ST1
0x1D7: SYNC_IRQ_VI6_SET_2
0x1D8: SYNC_IRQ_VI7_SET_3
0x1D9: (reserved)
0x1DA: (reserved)
0x1DB: ALGS_0
0x1DC: CCLIME_INT_CITRON_RDMA
0x1DD: HDMI0_1
0x1DE: DMA330_2
0x1DF: MDOMAIN_1
0x1E0: EDOMAIN_OPERA_OPEKICK5
0x1E1: EDOMAIN_EDMAC_6_WR_S3
0x1E2: EDOMAIN_EDMAC_2_RD_L0_B
0x1E3: EDOMAIN_EDMAC_7_CAP_RD_SS0
0x1E4: EDOMAIN_OPERA_ERR0
0x1E5: ORCA_B_11
0x1E6: SYNC_IRQ_INTE
0x1E7: SSIO_SSIOINT
0x1E8: SYNC_IRQ_INTVIO
0x1E9: (reserved)
0x1EA: (reserved)
0x1EB: ALGS_1
0x1EC: CCLIME_INT_CITRON_WDMA
0x1ED: HDMI1_0
0x1EE: DMA330_3
0x1EF: MDOMAIN_2
0x1F0: EDOMAIN_OPERA_OPEKICK6
0x1F1: EDOMAIN_EDMAC_6_WR_S4
0x1F2: EDOMAIN_EDMAC_2_RD_L1_B
0x1F3: EDOMAIN_EDMAC_0_OPERA_RD
0x1F4: EDOMAIN_OPERA_ABORT0
0x1F5: ORCA_B_12
0x1F6: SYNC_IRQ_INTE_ST1
0x1F7: SIO0_SIO0INT
0x1F8: SYNC_IRQ_VIO_SET_1
0x1F9: (reserved)
0x1FA: (reserved)
0x1FB: (reserved)
0x1FC: CCLIME_RESERVED
0x1FD: HDMI1_1
0x1FE: (reserved)
0x1FF: MDOMAIN_3
0x200: EDOMAIN_EDMAC_1_WR_L0
0x201: EDOMAIN_EDMAC_6_WR_SS0
0x202: EDOMAIN_EDMAC_2_RD_S0_B
0x203: EDOMAIN_EDMAC_6_DAN_RD
0x204: EDOMAIN_OPERA1
0x205: ORCA_B_13
0x206: DOLPHIN_IRQ_DOLPHIN_0
0x207: SIO1_SIO1INT
0x208: SYNC_IRQ_VIO_SET_2
0x209: (reserved)
0x20A: (reserved)
0x20B: (reserved)
0x20C: CCLIME_SLOTC_SDDAT1_INT
0x20D: SROMC0_OCTAL_IRQ
0x20E: I2C0_TIRQ
0x20F: MDOMAIN_4
0x210: EDOMAIN_EDMAC_1_WR_L1
0x211: EDOMAIN_EDMAC_6_WR_SS1
0x212: EDOMAIN_EDMAC_2_RD_S1_B
0x213: EDOMAIN_OPTI_RICH_A
0x214: EDOMAIN_OPERA_ERR1
0x215: ORCA_B_14
0x216: DOLPHIN_IRQ_DOLPHIN_1
0x217: SIO2_SIO2INT
0x218: SYNC_IRQ_VIO_SET_3
0x219: (reserved)
0x21A: (reserved)
0x21B: (reserved)
0x21C: SROMC0_QUAD_OIRQ_TX
0x21D: SROMC1_OIRQ_TX
0x21E: I2C0_RIRQ
0x21F: MDOMAIN_5
0x220: EDOMAIN_EDMAC_1_WR_L2
0x221: EDOMAIN_EDMAC_6_WR_SS2
0x222: EDOMAIN_EDMAC_2_RD_S2_B
0x223: EDOMAIN_OPTI_LITE_A
0x224: EDOMAIN_OPERA_ABORT1
0x225: ORCA_B_15
0x226: DOLPHIN_IRQ_DOLPHIN_2
0x227: SIO3_SIO3INT
0x228: (reserved)
0x229: (reserved)
0x22A: (reserved)
0x22B: (reserved)
0x22C: SROMC0_QUAD_OIRQ_RX
0x22D: SROMC1_OIRQ_RX
0x22E: I2C0_SIRQ
0x22F: MDOMAIN_6
0x230: EDOMAIN_EDMAC_1_WR_L3
0x231: EDOMAIN_EDMAC_6_WR_SS3
0x232: EDOMAIN_EDMAC_2_RD_S3_B
0x233: EDOMAIN_OPTI_RICH_B
0x234: EDOMAIN_HAIDI_PNL
0x235: ORCA_B_16
0x236: DOLPHIN_IRQ_DOLPHIN_3
0x237: SIO4_SIO4INT
0x238: (reserved)
0x239: (reserved)
0x23A: HARB_HARBINT
0x23B: RSTGEN_WDTINT
0x23C: SROMC0_QUAD_OIRQ_FAULT
0x23D: SROMC1_OIRQ_FAULT
0x23E: I2C1_TIRQ
0x23F: (reserved)
0x240: EDOMAIN_EDMAC_1_WR_L4
0x241: EDOMAIN_EDMAC_6_WR_SS4
0x242: EDOMAIN_EDMAC_3_RD_L0_A
0x243: EDOMAIN_OPTI_LITE_B
0x244: EDOMAIN_HAIDI_LINE
0x245: ORCA_B_17
0x246: DOLPHIN_IRQ_DOLPHIN_4
0x247: SIO5_SIO5INT
0x248: (reserved)
0x249: TSENS_IRQ_TSENS
0x24A: MCPU_DECERRINTR
0x24B: MCPU_L2CCINTR
0x24C: SROMC0_QUAD_OERR_COLLECT
0x24D: SROMC1_OERR_COLLECT
0x24E: I2C1_RIRQ
0x24F: (reserved)
0x250: EDOMAIN_EDMAC_1_WR_L5
0x251: EDOMAIN_EDMAC_6_WR_SS5
0x252: EDOMAIN_EDMAC_3_RD_L1_A
0x253: EDOMAIN_JP52_1
0x254: EDOMAIN_HAIDI_EVF
0x255: ORCA_B_18
0x256: GLDA
0x257: SIO6_SIO6INT
0x258: MARIO_0
0x259: DEBSIO
0x25A: MCPU_ECNTRINTR
0x25B: MCPU_PMUIRQ_0
0x25C: INT_TM_MISC_CPU_HANDSHAKE0
0x25D: INT_TM_MISC_CPU_HANDSHAKE1
0x25E: I2C1_SIRQ
0x25F: ADOMAIN
0x260: EDOMAIN_EDMAC_1_WR_M0
0x261: EDOMAIN_EDMAC_6_WR_SS6
0x262: EDOMAIN_EDMAC_3_RD_S0_A
0x263: EDOMAIN_JP52_2
0x264: (reserved)
0x265: DMA330_ABORT
0x266: XIMR
0x267: SIO7_SIO7INT
0x268: MARIO_1
0x269: MCPU_SCUEVABORT
0x26A: MCPU_SLVERRINTR
0x26B: MCPU_PMUIRQ_1
0x26C: MONI_MONIOUT_0
0x26D: MONI_MONIOUT_1
0x26E: MONI_MONIOUT_2
0x26F: MONI_MONIOUT_3
0x270: INTC_ANDINT_0_0
0x271: INTC_ANDINT_0_1
0x272: INTC_ANDINT_0_2
0x273: INTC_ANDINT_0_3
0x274: INTC_ANDINT_0_4
0x275: INTC_ANDINT_0_5
0x276: (reserved)
0x277: (reserved)
0x278: (reserved)
0x279: (reserved)
0x27A: INTC_ANDINT_1_0
0x27B: INTC_ANDINT_1_1
0x27C: INTC_ANDINT_1_2
0x27D: INTC_ANDINT_1_3
0x27E: INTC_ANDINT_1_4
0x27F: INTC_ANDINT_1_5
I assume this interrupt table is valid for all DIGIC X models (At the time of this post that are EOS R6 and EOS R5).
Therefore the interrupt vectors for UART (needed for qemu) are:
0x0DD: UART0_RX_INTREQRX
0x0ED: UART0_TX_INTREQTX
Hi,
I have a R5 at hand. Can I help with the development process?
Unless you know embedded C / ARM assembly or willing to spend a lot of time to learn it, at this moment - no.
I'm about to buy my Canon r6. I've had excellent success with ML on my 6D over the years. Can I still extend the video time with ML for the r6? It looks like there was some confusion about that. Also, I don't see it in the downloads, so where do I download ML for the r6? I honestly did search the forums a bit before asking this question. Is it missing from that page because it's not yet stable?
There is none and there will be none for the foreseeable future.
oh man, that sucks. Is it because it requires a completely new build and it's a challenge or is there no demand for one?
Lack of manpower.
Will it be prioritized for r5?
Also, I'd like to thank you for helping so many on these forums over the years. You immediately answered my questions back in April 2019 and got me hooked on Magic Lantern in the first place!
Quote from: NoHinAmhherst on August 10, 2021, 05:15:20 PM
Will it be prioritized for r5?
Wrong concept. ML project has no timeline, no project plan, no schedule. If someone has time and skills and a camera to work on it is completely up to this person.
So there is no effort to do it for those cameras so I should never expect it -- no forum about the effort or place to collaborate or get updates. But maybe it will happen on any timeline imaginable if someone with the skills and interest takes it on. Got it.
Happen to have a R5 here and I noticed something which I haven't seen mentioned anywhere else around.
When recording in raw(internal 12 bit), selecting the Canon Log3 option does have influence on your raw data.
Side to side comparison in DaVinci Resolve, canon log 3 activated, and canon log settings to off, shows that activating Canon Log 3 means that the camera is actually recording at an ISO value of 3 stops lower.
Please test yourself.
Record something in 8K raw at iso 800 and with canon log 3 activated. (use fixed value for shutter time and aperture)
Now record the same in 8K raw at iso 100 without canon log 3 activated. (with same aperture and shutter speed ofcourse )
Now load both files in DaVinci resolve, go to the raw tab in color mode, and set both to:
Decode quality -> Full res - Canon
Decode using -> clip
Colorspace -> canon cinema gamut
Gamma -> canon log2
iso -> 800 (both files to 800 to match iso 100 recording to iso 800 recording)
Now look at the parade waveform, it's identical, max highlight data, noise in the shadows etc.
Now when recording in raw, and having canon log 3 activated, the lowest iso you can choose is iso 800, which makes senses, because in the background, it actually records 3 stops lower in iso 100, to save the highlights.
Also, when comparing footage recorded in iso 12800 with log 3, it's the same as normal non log raw at iso 1600. Same highlights, same shadows, same noise.
So when recording in raw, maybe better to not have canon log settings activated :P
All of the above applies for internal raw recording.
The above means, that in canon log 3, shadow data is pushed in post by three stops.
This is a lot and is the reason for shadow noise in log footage.
For non raw recording, and also for the R6:
If you're recording a low dynamic range scene (8 stops or lower), it could mean that you might be better of with exposing to the right and not use canon log 3.
This way, you could have cleaner shadows I guess (not sure, not tested it :P)
Quote from: Levas on January 29, 2022, 03:56:35 PM
The above means, that in canon log 3, shadow data is pushed in post by three stops.
This is a lot and is the reason for shadow noise in log footage.
For non raw recording, and also for the R6:
If you're recording a low dynamic range scene (8 stops or lower), it could mean that you might be better of with exposing to the right and not use canon log 3.
This way, you could have cleaner shadows I guess (not sure, not tested it :P)
Thanks a lot, Levas, for this important experiment. I was kind of suspecting that Log 3 in R5 and R6 works as you described but never had the opportunity to get hold of one of these cameras to test. I am glad you did it. Now it may turn out that the good old 5D3 with its Dual ISO and carefully exposing to the right may provide cleaner shadows results than the R5/R6 with the Log 3 profile. I have been playing around a lot with the high-resolution anamorphic modes on the 5D3 and the 700D and got very clean shadows results on both of them. This is also confirmed with the latest results by 70MM13 who gets extremely clean footage in dark high-contrast scenes with his 5D3 even without Dual ISO. As a bonus, we also get this organic and naturally looking RAW footage provided by ML.
I was wondering if you made any comparative experiments with your 6D vs. R5/R6. No wonder if we get to see some interesting surprises here.
Quote from: IDA_ML on February 01, 2022, 07:56:06 AM
I was wondering if you made any comparative experiments with your 6D vs. R5/R6. No wonder if we get to see some interesting surprises here.
Not yet, want to do some tests outside, but the weather is not that inspiring last few weeks :P (clouds/wind/rain)
I'm very curious about comparing the 6d in dual iso mode (for photos), the R5 has more dynamic range at iso 100, but 6d has dual iso.
And maybe some other things to compare, ML raw 14 bit video on 6d vs canon 12 bit video on R5.
Photons to Photos has data for 6D with ML: https://www.photonstophotos.net/Charts/PDR.htm#Canon%20EOS%206D,Canon%20EOS%206D(ML),Canon%20EOS%20R5
...
(https://kitor.pl/eos/img/r5_th.jpg) (https://kitor.pl/eos/img/r5.jpg)
That took countless hours spent in qemu.
And then 60 hours extra debugging on physical camera why it crashes.
Turns out that new bootloader (introduced around I think 850D) erases whole destination buffer if autoexec.bin is loaded.
It just happens that before that, the same RAM regions are initialized for coprocessors like EF comm (SHIRAHAMA) and EIS (KUSATSU).
And DryOS was very unhappy if booted in that state, crashing immediately in different places.
So far - R5 has total 5GB of DDR4 RAM - 2x 512MB and 2x 2GB.
How this is mapped - it is unknown. smemShowFix is gone. Looks like whole old Resource Manager is gone and replaced with RscMgr2.
Drawing routines also had to be adjusted, as while interface still seems to be 720x480, buffer is 2048x1080 (it was 960x540 in the past).
I saw some differences in FIO routines.
Bootloader says it has 1 gig of RAM. My theory so far is that 2x512MB are used by main ARM core and 2x2GB by peripherals - and those are memory mapped into ICU where needed (as there's about 1GB of address space left).
Very rough and unpolished code is on my branch: https://github.com/kitor/magiclantern_simplified/tree/R5
Good work!
To clarify, there is a memory region that on some cams, Canon code zeros out if autoexec.bin is selected to run. On R5, some parts of that region hold data that must be involved with early device setup for peripherals / co-processors. During a normal boot, the zeroing doesn't happen and everything is okay. Presumably, when Canon does whatever tests they run using *their* autoexec.bin, they don't try to transfer control back to the cam to finish the normal boot, so everything is okay. It's only when autoexec.bin gets used, *and* you transfer control back to Canon, that the conflict triggers problems; presumably something is reading the zeros and needs real data instead.
Slightly earlier cams zeroed a region but it was small enough it didn't conflict. Or, at least, not as badly. We need to fully confirm this by checking code in other Digic 6, 7, 8 cams. Perhaps we're lucky and kitor has found the cause of some problems on those cams, too.
Quote from: kitor on April 12, 2022, 10:22:29 PM
(https://kitor.pl/eos/img/r5_th.jpg) (https://kitor.pl/eos/img/r5.jpg)
Great, can't wait to have raw video on this camera ;D
(Sorry for the stupid joke, had to make it :P)
Curious if the R5/R6 still have the CMOS registers used for controlling iso.
Want to know which is the highest CMOS iso and from which point it's only amplified gain.
From tests I guess it's either iso 1600 or 3200 which is highest sensor iso.
And ofcourse if dual iso still exist, two separate iso settings.
Quote from: Levas on April 13, 2022, 08:32:00 PM
Great, can't wait to have raw video on this camera ;D
To be honest I was sad I got it after April 1, as it would make a great headline for April Fools.
As for CMOS registers I'm not sure if we even still have those on D78.
We are still in "too early" stages , trying to solve instability issues on much basic level (eg. Digic 8 random crashes related to LiveView, probably due to how we draw ML interface).
For sure script to detect timings can't get anything from EOS R. A ton of things is getting offloaded into secondary cores.
If will be nice to have anyone of the "old guild" with deeper hardware understanding to have a look at D6/7/8 models (even if this means poking around ROMs and not real hardware). Unfortunately Alex is gone for almost a year now.
Is it possible to transfer firmware from upper models or hack/activate at least only raw-video in R6?
they all have the same processor and memory-card support with R5/R3, and this is only a software limitation ...
I don't need the super abilities of cameras above R6, but I need RAW-video..
+ R6's is lower MP, making pixel size bigger and do it less noisy for video.
I dream that RAW video becomes possible on R6...
How many chance to it we have now in % ?
Quote from: nothuman1 on April 14, 2022, 01:24:53 PM
Is it possible to transfer firmware from upper models or hack/activate at least only raw-video in R6?
(https://media.makeameme.org/created/thats-not-how-31g08n.jpg)
https://wiki.magiclantern.fm/faq#troll_questions
Angry Walter, that's an achievement!
QuoteIs it possible to transfer firmware from upper models or hack/activate at least only raw-video in R6?
Yes? No? Maybe? Even if, it will be illegal and bring whole project into a legal trouble, so feel free to experiment on your own. You won't get any definitive answer or help here.
Quote from: kitor on April 14, 2022, 08:59:19 AM
will be nice to have anyone of the "old guild" with deeper hardware understanding to have a look at D6/7/8 models (even if this means poking around ROMs and not real hardware). Unfortunately Alex is gone for almost a year now.
Always amazed me how far magic lantern has come with digic 5.
With the whole raw video development.
This whole thing about A timer, B timer, shutterblanking, capturing the raw stream and write it to sd.
I wonder how somebody can figure such things out, with reversed engineering. Alex must have broad knowledge about digital image capture.
What kind of people become good at reversed engineering, must be some work related thing. Or are there people out there who figure this out as hobby?
There must be some basic knowledge about firmware and product development I guess.
@Kitor, how did you learn how to get 'hello world' on various cameras?
Has the knowledge you need for that overlap with your work ?
Quote@Kitor, how did you learn how to get 'hello world' on various cameras?
Has the knowledge you need for that overlap with your work ?
It just happened that I was at the right time in the right place (Discord) just when the digic6+ task context struct got finally cracked.
No, my actual work background is devops-ish, I work as continuous integration/delivery engineer (and now architect). In fact, before I joined the efforts I had about 8 years gap since the last time I touched C/C++.
One of my hobbies is old computers (I have quite a big collection) and I watched a lot of videos about 8 bit computer internals or how each generation of consoles was hacked. I guess I had the general idea of what is going on, so it was easier to jump in.
Digic 6 - 8 bootloaders (except latest iterations on 850D, R5/R6) are very similar. This is mostly just stubs hunting, and for hello world you don't need that much of them.
R5/R6 was a little harder. 850D already had "the new/improved" stage 1 bootloader, but due to a different memory layout @Names had no issues there.
Even with that, the Digic 6 - X boot code implementation is common with just some minor differences in stubs/constants required on per generation basis.
When @Lorenzo got his R6, I took that as an opportunity to dig a bit more into QEMU (well, that took a few days of work), so we had "working" builds there. But those were not booting on real hardware. Thus it was known that there has be a catch. That is what ended up into around 60 hours of debugging on real hardware - my R5 so far crashed more times that it made photos ;)
Interesting, so most of the knowledge is based around hobby and not that much career/work related.
Grew up with the commodore 64 and amiga 500. But all we did back then was playing games :P
No programming. Although later on I did a lot in microsoft quickbasic as a hobby. Even made a working tetris game in quickbasic.
With photography as a hobby( and Canon shooter) I found out about the Magic Lantern site in the 5d2 area. Read a lot on the forum. Later on when crop recording was introduced by alex I could help by changing the values in the already written crop_rec module.
Just changing numbers in the code and test it on camera, that's about as far as my programming knowledge goes :P
Would be cool to dive some more into this, but not sure what knowledge would be most helpfull.
Maybe setup a working qemu build or better understanding about the Magic lantern source code ???
It is not too hard to learn, if you have some programming background. We can answer a lot of questions on Discord (it's easier there because it's faster). C is the primary language.
I've done some work to make building ML and building Qemu considerably easier.
Hi guys, I'm back.
after many years of shooting any kind of project with MLV on myy 5DIII, I added to my set other brends cameras and now I added the the R5.
I see you guys are altready working on this model. You're awesome!
Since this camera is already quite complete out of the box (IMO), I think a lighter and non invasive version of ML would suite this camera perfectly, with just the most needed features in favour of stability.
If I'd have to suggest something to help, my priorities would be:
- 30 mins recording time limit removal (maybe only on lower resolutions or via HDMI to preserve the camera from overheatng?)
- Canon Raw recording through USB port for USB SSDs (Jus a routing from CFexpress to USb or even a dual recording). I know this camera has a USB 3.2 Gen 2 (10 GBit/sec) and Canon states the minimum CFexpress specs, even for 8K raw, are CFexpress 1.0 [400MB/sec. or higher] so on paper the USB controller could handle it.
- A way to record 4K 120fps in raw, even for a limited time. I think this could not be done with the same raw format from Canon, right?
In case you need it I'm available for testing.
Thanks.
I don't want to shatter your dreams, but forget about it.
I can agree that it is mostly complete out of the box. From the list you provided, maybe 30 minutes limit can be removed the same way as on previous generations.
Other things - unlikely to happen.
Please bear in mind that Digic X is another generation of unknown hardware - but this time capable of doing raw natively. And as I stated before, a fundamental part of OS (Resource Manager) got completely replaced, which will break a lot of things. Not to mention that RAW is R5/R3 domain only - we don't touch R3 and as of R5 goes I am the only dev here with R5. And with a lot less time to invest lately due to "away from keyboard" stuff :)
Quote- Canon Raw recording through USB port for USB SSDs (Jus a routing from CFexpress to USb or even a dual recording).
Impossible. CFExpress is just DMA over PCI Express, USB - even if camera had USB host functionality (and to my knowledge it doesn't) handling overhead and lack of implementation would be most likely too much to achieve it without a significant effort - if possible at all.
From the glimpses of new File I/O I saw - it seems that file I/O is hardware accelerated now (probably DMA using what is called IBus - Image Bus?).
Yes, I know Magic Lantern is famous for crossing items out of "troll questions" list, but if comparing against "well supported" generations, Digic 6 and newer models are in "early 2011" state of things, or worse.
(https://kitor.pl/eos/img/r5_menu_th.jpg) (https://kitor.pl/eos/img/r5_menu.jpg)
https://twitter.com/_kitor/status/1533767862531268608
WIP PR open: https://github.com/reticulatedpines/magiclantern_simplified/pull/62
This already has some challenges to be solved. At this state none of the features work (ok, I lied, it can display connected lens info :) )
Wanted to know some more how the camera(Canon R5) behaves under different modes and different iso settings.
Shot some dark frames in different photo and video modes and loaded the into raw digger to calculate dynamic range based on noise.
Made a spreadsheet in google drive with some more info about the Canon R5:
https://docs.google.com/spreadsheets/d/1D3lpiMQniUzPiaVqDzAs5Gmc2hR9mIjDXpDe5IBTP9E/edit?usp=sharing (https://docs.google.com/spreadsheets/d/1D3lpiMQniUzPiaVqDzAs5Gmc2hR9mIjDXpDe5IBTP9E/edit?usp=sharing)
What suprises me are the different black levels.
In photo mode in iso 100 and iso 200 it's about 512.
While in all other iso modes it becomes 2048 (which is normal for most Canon camera's with digic 5 with ML support).
In raw video mode black level is 1024, all iso's also iso 100 and 200.
The Canon 6d always has black level in the 2048 range, unless when shooting 12 bit or 10 bit raw, then it becomes 512 and 256)
Does this mean that the Canon R5 is using 13 bit a/d conversion for video modes ? (would explain the black level shift from 2048 to 1024)
And what is going on with iso 100 and 200 in photo mode, the only modes where black level is 512, can't be because 12 bit a/d conversion I guess, dynamic range is highest at iso 100 ???
Furthermore, it seems that iso 200 can be best avoid(dynamic range wise), if 100 is not enough, you can go directly to iso 400 :P
Also, after iso 3200, every more stop of iso is a direct stop loss in dynamic range, so there is probably not much reason to shoot higher then iso 3200, since digital exposure push in post should give similar results.
So anyone has any idea what's going on with the different black levels, especially the black level of 512 with iso 100 and 200 in photo mode?
What is also interesting, when shooting raw video in the raw lite codec, which has a compression ratio of 6:1instead of normal raw which has 4:1 compression ratio.
The max white value of both green channels become about 10780, not 15359. (16383(max 14 bit value) - 1024(black level) = 15359)
Both the red and blue channels still have 15359 as maximum white level.
So the extra compression is achieved with using lower values for green channels, which according to the measurements done with dark frames doesn't impact dynamic range.
Weird enough, there seems to be a slight advance in dynamic range when shooting raw lite instead of normal raw ???.
Although this probably comes with a penalty of less fine detail, since the green channels seems to contain more noise reduction done already in camera, or the standard noise reduction kicks in more because of the lower values.
For those interested, some comparison of raw video against the 6d.
Was hard to do, not easy shooting the same scene and layering the footage and matching colors etc. :P
8k raw of the R5 scaled to ultraHD matched to aspect ratio of the 3x1 mode of the 6d.
It starts with R5 footage and wipes to 6d footage (3x1 mode, 1832 x 1856 -> 5496 x 1856 resolution scaled to ultraHD)
The footage is very comparible, but R5 wins on detail, far more detail in the leaves.
And the R5 can shoot more usable aspect ratios of course :P (R5 footage aspect ratio is matched to 6d 3x1 mode.).
https://drive.google.com/file/d/1c059wQoWCMJmlSClCrJ7aq2N7DgEv2r8/view?usp=sharing (https://drive.google.com/file/d/1c059wQoWCMJmlSClCrJ7aq2N7DgEv2r8/view?usp=sharing)
Another comparison, here the 6d is used in crop mode 2880 x 1200.
The 6d footage is placed on the R5 footage which uses the whole frame.
So the frame somewhere in the middle is the 6d footage.
https://drive.google.com/file/d/1ktI5tKHdYd80gjpT6c5AdFYYRvTDsdVq/view?usp=sharing (https://drive.google.com/file/d/1ktI5tKHdYd80gjpT6c5AdFYYRvTDsdVq/view?usp=sharing)
Quote from: Levas on June 10, 2022, 07:44:37 PM
The Canon 6d always has black level in the 2048 range, unless when shooting 12 bit or 10 bit raw, then it becomes 512 and 256)
I don't have 6D anymore, but how could you shoot 10 bit RAW with it?
Quote from: Levas on June 10, 2022, 07:44:37 PM
So anyone has any idea what's going on with the different black levels, especially the black level of 512 with iso 100 and 200 in photo mode?
We had some trouble with my G1x and the Black level. This is also issue for some P&S.
The M100 changes its black level from 512 to 2048 at around ISO320.
May be something interesting for you:
https://chdk.setepontos.com/index.php?topic=12165.30
https://chdk.setepontos.com/index.php?topic=7069.0
But is changing black level from 512 to 2048 losing of 2 Bit?
If I have a maximum exposed pixel with 16383 and I half the exposure, then theoretically the value goes 16383/2 = 8192.
What I see is on my G1x:
With black level 512 => ((16383 - 512) / 2 ) + 512 = 8848
With black level 2048 => ((16383 - 2048) / 2 ) + 2048 = 9216
The RAW values in 1EV steps with black level 512 can be seen here
https://chdk.setepontos.com/index.php?topic=12165.msg126374#msg126374
That's a great comparison, thanks very much!
The darks were far better on the R5 also. Nice and crisp detail on the trunk of the beech tree. The 6D was just mud.
If you are so motivated, a comparison of a very dark scene would be much appreciated, with the shadows lifted several stops...
@C_joerg
Interesting, so black level changes happen on more canon cameras.
Not sure if I understand the stuff discussed in the links you send.
So am I right that one theory is that the camera actually uses a lower iso then it actually reports ?
So in case of the Canon R5, which only has black levels of 512 in iso 100 and 200, you think it actually uses a lower iso/gain, like 25 or 12.5 ?
Iso/gain is the only thing they can use, a faster shutter speed or smaller aperture would both be noticed by people I guess.
The 10 bit and 12 bit raw recording is possible on the 6d with raw video recording in magic lantern raw.
This was done by using a register that act as digital gain, it pushes the values recorded 2 or 4 stops lower.
Now I think about it, that makes sense that in this case the black level becomes lower in value.
Digital negative gain also lowers the noise signal, so this means lower black level ???
What I also see discussed in the links you send, is that the image data is rescaled in the raw files in camera.
This is also the case with the R5, max white value is always at 16383 - black level.
This makes it difficult to see what is going on...
The whole iso magic is also happening with clog1, clog3, highlight tone priority etc.
Minimum iso that is possible in 8k raw:
No log -> iso 100
Highlight tone priority enabled -> iso 200
Log1 -> iso 400
Log3 -> iso 800
When actually using the above settings and iso, and load the files in raw digger, you can see in the noise level that it's all the same, it's all recorded in iso 100 :P
i like the 6d footage better
Been a while since I was on the ML forums - recently upgraded from a 5DMK3 finally to an R5, already missing some magic lantern functions...
didn't read through all 12 pages, do we have a semi-stable build that works on the R5 now?
No.
Quote from: HondaATC on December 22, 2022, 03:52:28 PM
Been a while since I was on the ML forums - recently upgraded from a 5DMK3 finally to an R5, already missing some magic lantern functions...
Would love to hear specifically which ML functions you are missing switching from 5D3 to R5. A genuine, non-rhetorical question.
Well regarding ML functions and Firmware development: wouldn't it be possible or even be easier to port cinema menu functions from the R5 C to R5, since they are almost the same camera and (i guess) most of the features are pure software implementation? I know this is far away from easy but just thinking maybe someone with more knowledge than me might poke around in the R5 and R5C firmwares and might find something interesting and/or usable?
Quote from: C0dR on December 23, 2022, 09:28:26 AM
Well regarding ML functions and Firmware development: wouldn't it be possible or even be easier to port cinema menu functions from the R5 C to R5, since they are almost the same camera and (i guess) most of the features are pure software implementation? I know this is far away from easy but just thinking maybe someone with more knowledge than me might poke around in the R5 and R5C firmwares and might find something interesting and/or usable?
Not gonna happen. It would be a violation of Canon's IP for sure.
Example what is considered to be allowed:
Canon introduced an electronic zoom for video in EOS 600D. Better image quality but cropped.
Same code was found inside 650D, 700D, 100D, EOS M. Just no menu item for the function to get accessed (simply speaking). So ML devs used what they found.
Example what is considered to be a no-go:
AF adjustments are not available for entry level cameras. Such code is not present in cam firmware then. It was asked several times to make it happen but it was declined because of IP issues.
Quote from: vastunghia on December 22, 2022, 09:54:17 PM
Would love to hear specifically which ML functions you are missing switching from 5D3 to R5. A genuine, non-rhetorical question.
Focus Peaking for video and zebras in over exposure places on image review are the main thing so far. Magic zoom was also really handy.
Seems like there was also some custom button programming I did that I can't figure out how to replicate on the R5 (like changing the ISO by holding the select button and just rolling the front switch). Maybe that was a normal canon setting but its been so many years ago I don't remember how i configured it.
Maybe the R5 can do all of these things, but I haven't figured out how yet.
Quote from: HondaATC on December 23, 2022, 01:24:20 PM
Focus Peaking for video and zebras in over exposure places on image review are the main thing so far.
I see. However with 5D3+ML in many cases focus peak and zebras (as well as raw histograms, fwiw) are pretty unusable — that is, they work bad with correct framing and are anyway hard to use with the small cam LCD (even with real time, cropped preview that is).
An external monitor does the trick I think, both with 5D3+ML and with R5. Actually, I guess you will also get correct framing with R5+monitor, which is not the case with 5D3+ML+monitor.
Just my 5 cents.
S
Hi, I did some review on the R6 Mark II, for low light photos only. It is in french here :
https://www.webastro.net/forums/topic/236222-test-complet-canon-eos-r6-mark-ii/
I also found it has the two offsets of 512 below 320 ISO and 2048 from 400 ISO.
The 200 ISO setting is worse (noise/dynamic) than 100 and 400 ISO.
Strange thing happens to the RAW when looking at the FFT of the bias images, two horizontal lines below and above the central module line... maybe due to Dual Pixels ?
Fred
For those wondering what the Digic X issues are, here is the list:
https://github.com/reticulatedpines/magiclantern_simplified/issues/80
https://github.com/reticulatedpines/magiclantern_simplified/issues/81
https://github.com/reticulatedpines/magiclantern_simplified/issues/82
TL;DR: Like I described in this post (https://www.magiclantern.fm/forum/index.php?topic=24827.msg238467#msg238467), memory management is interesting.
Camera appears to have 5GB of RAM (4+1) that maps somehow into <2GB of memory space on ICU.
There's a new resource manager that seems to handle that. There's not a lot of debug prints though, I tried to understand it for a few days but got nowhere.
I personally gave up on this for now, since I believe we have a whole backlog of Digic 6, 7 and 8 models to support. And as for now, only R5 and R6 would benefit anyway - as we already know newer R models have Canon Basic and UART ocked - which means there's no (easy) way to run the code on them... at least for now.
I understand giving up. Since the overheating isn't an issue anymore, I'm not sure how ML would benefit the R5 or R6 much anyway unless it can somehow let us do Open Gate recording.
R6 has 20,1 effective megapixels and 21,4 total megapixels. Including the optical black field to the left and top I get 5568x3708 pixels. Total 20646144 pixels. Where are the others? To the right and trashed before saving to card like 5D III?
https://d1hjkbq40fs2x4.cloudfront.net/2020-07-03/files/canon-eos-r6-image-sensor_2061-03.JPG
Quote
R6 has 20,1 effective megapixels and 21,4 total megapixels
Got a source for that 21.4 MP? I suspect it's just wrong.
Quote from: names_are_hard on April 02, 2023, 07:20:29 PM
Got a source for that 21.4 MP? I suspect it's just wrong.
It's actually written on Canon UK, R6 specs (https://www.canon.co.uk/cameras/eos-r6/specifications/):
(https://i.ibb.co/m0mM5n8/R6-Pixels.png)
Also found in EXIF data
(https://abload.de/img/2023-04-0219_29_08-exy2eef.png)
And
Image Width/Height is 5472x3648
Lots of different numbers from different sources then.
Listed image resolution is 5472 x 3648 (19.9MP?). That's usable data I suppose. Exif suggests 20.6MP. Size with masked areas?
No idea how 21.4 is calculated. Perhaps it's the same inflation that leads to 19.9 being reported as 20.1?
RAWtherapee tells the picture I used for Exiftool is actually 5488x3662=20,097,056 which is legally rounded to 20.1
No, don't ask me why exif shows different numbers.
A1ex mentioned about some columns not saved in the raw file for 5D III https://www.magiclantern.fm/forum/index.php?topic=10111.msg104609#msg104609
Could be. I don't have an R6 so can't investigate (and don't care enough to bother anyway).
Quote from: vastunghia on December 22, 2022, 09:54:17 PM
Would love to hear specifically which ML functions you are missing switching from 5D3 to R5. A genuine, non-rhetorical question.
I'm 5D3 1.23 ML user and I find it
invaluable for exposure bracketing, and also bracketing with flash enabled with 2s delay. You may ask why would I want to do that, and basically for real estate work you really really really really want to be able to do that without manually tweaking settings like 5-6 times per single composition and every time knocking camera off by a pixel or two. Even basic bracketing is such as guesswork with any camera including R6. If you are lucky guesstimating your brightest exposure (or else you take a spare unasable blown out frame) you typically don't go down enough leaving those blown highlights even at -5EV or so. Histograms are useless, screens are small so until you load images to LR you don't even know you have a window or sky still blown out. So guess what I'm still taking 5D3 to jobs as the main cam and R6 and 5Ds are backups. 5ds is pretty inevitable for high res work and I just dialed in bracketing to 5 frames every 1 2/3 stops. It sounds excessive and it is but at the same time, it can be not enough, and that is also true to R6 if you stick with 3 frames 2EV apart.
Other that that I use RAW histogram, focus red overlays and digital focus range display all of which canon still doesn't quite want to give us in full in all modes.
I don't really care about RAW video on the 5D3 anymore since getting the R6. that is so so much better. R6 RAW would be nice, and mkII sort of does that once you get the NINJA V+ recorder. So really the focus IMHO are now all about photography features.
I find the former feature so important that I am rather going to jump to another brand if I need to rather than stick with Canon once 5D3 gives up. I believe Z9 has more of this functionality (the flash part), but not smart auto bracket limit feature unless I'm mistaken. I can adapt that 16-35mm lens and buy GODOX trigger for any new system so if there is one that does all that natively please let me know.