Messages

Alright,
Nothing quite new regarding 60fps 3x3 on the 70D, but here is the requested screenshot with the overidden registers and a screenshot of the frame it produces. As you can see it still got some artifacts and the frames also freeze from time to time during recording. 





Also, I am able to compile now (yay - thanks @dfort for helping me set up an environment). However, as I already said before, I have ZERO coding experience so with regard to the requested functions you'd have to tell me exactly where to insert them in the code.

Totally unrelated. As I know nothing of the architecture of the cams I'm not sure if that's relevant but the reason why I decided for a 70D in the first place is that it's the only cam that runs ML with dual pixel AF, right? Maybe that's why some things work differently? Just a random thought.

As for the crop_rec experiment, I still have the same problems of stuttering (because fps override doesn't work on the 70D I believe), but I also think I'm really onto something. In the link below I shot a scene which I know produces extreme moire and color artifacts for me when shot in 720p mode, but as you can see, in the crop_rec mode this is greatly reduced. This really is the improvement in image quality in 720/60p mode I was looking for, but I guess in order for it to work properly I have to get more familiar with the registers and above all compiling...  .  https://we.tl/t-14HITuZvg6

Canon EOS 70D 1.1.2
00f0000a:     5f1 ISO=800 Tv=160 Av=28 lv=1 zoom=1 mv=1 res=1 crop=0 task=Evf pc=49fb4 addr=404e7874
00f0000b:     800 ISO=800 Tv=160 Av=28 lv=1 zoom=1 mv=1 res=1 crop=0 task=Evf pc=49fb4 addr=404e7876
0002800c:       4 ISO=800 Tv=160 Av=28 lv=1 zoom=1 mv=1 res=1 crop=0 task=Evf pc=4b5e8 addr=404e5e1c Line skipping factor (2 = 1080p, 4 = 720p, 0 = zoom)


Is this the right format of the log? Yes I am trying to get the 720p/60fps mode to work with 3x3 binning, trying to follow instructions that dfort gave back in march  . Anyway, what I did was

ADTG2[800c] from 4 -->2
CMOS (b) from 800 --> 200  (this is the only value that differs from 1080p mode, its 400 in 1080p
CMOS (a) from 5f1 --> 1f1

Unfortunately I am still not able to compile, I am trying to get there. My method atm was to find registers that change when switching video modes and trying to find combinations that work. In other words, using brute force

I found a reproducable way to get h264 AND raw recording, without the white borders !!! It still got the pink and green pixel and the lag but its working fine otherwise !!
I had to overwrite CMOS(b) to 200 (from 800, value in 1080p is 400) and CMOS(a) to 1f1 (from 5f1, value in 1080p is also 1f1 !!)
I think in my original attempt I didnt refresh the live screen often enough to see which register had which impact
Here's the Link
https://we.tl/t-Ea1XGM5Rkw

As always, hope this helps !

Hey everyone! I think I made a major step forward with the crop_rec module. I discovered that the weird stripe patterns go away when I change CMOS(b) from 0x800 to 0x600. Oddly enough the value in 1080p mode is 0x400! Video in the link is the one I recorded with both ADTG[800c] and CMOS(b) changed!

https://we.tl/t-XlugLACvNW

Is this as useful as I hope it is  ?

Had a little time at hand (havent had too much of that lately unfortunatley), and I am trying to get back into the line skipping/binning experiment here, and I observed something. The task was to change the ADTG2[800c], but are we sure that is the right register? It only appears after I played back a h.264 file, not after I recorded it. I can only see it when all 567 something registers are visible, when I stay in video mode (without playback) and go into 5x or change to 1080p, the maximum I can see are 160 something registers.

Should the ADTG reigster I am looking for change when I go into 5x zoom mode? Because there are some that do. I am trying to wrap my head around where I should start looking. In other words - what is an action that I can implement that should defintely move the register I am looking for?

In post #3111 a1ex said that the CMOS registers are likely different. does that mean the VALUE for ADTG2[800c], or a different register alltogether?

It seems to me that this is a task that could potentially be solved, since lossless compression appears to be too complicated for mere earthlings . It would also mean that with the new sd card overclocking feature the 70d could venture into useful slow-mo terretory (in case anyone else with a little time and limited knowledge needed an incentive - or am I missing something?)

As always, thank you everybody for contributing,
Cheers Dave

ok! so with a little care and lots of reading the test you linked should be doable i suppose! only out of curiiosity - am i the first one to try this? nikfreak owns a 70d right? just asking bc I may run into very specific problems (or findings?) others may have already encountered. If I ever get this far. I'll start reading up!

Ha! Yes, disabling the exposure simulation was something along the lines of what I was thinking about. However, the solutions you suggested are obviously a lot more elegant. Can't wait to see how the mechanical shutter simulation by way of the aperture works out! Thanks for answering the question and also grant us a look into the future .

I dont think you understand my question correctly. I am NOT searching for a simple fix to make the shutter speed faster - I read quite a bit of this thread, enough to understand that 1/30th is the current limit. However (and here's the correct me if I'm wrong part again) I seem to recall that a1ex achieved 1/30 with a shutter speed setting of 8000 on the camera. When you set your shutter to 8000, liveview darkens siginificantly. My question was aiming at a possible solution like tricking the module into "always" selecting the highest possible shutter speed without the need to set it to 8000 on cam.

Hey! I got a question. I just recently started using silent pics and I love it so far. I think that you obviously wouldnt shoot sports with it, 1/30th of a second isnt too shaby - very useful for ceremonies or other kind of event where shutter noise is a no no as others have noted. I just wondered if it is possible/feasible to impement a mode that tells the cam to set the shutter speed to 8000 automatically AFTER the half shutter was pressed. This way one could use the Live view for normal preview (bc it darkens when you choose the higher shutter speeds) but ensure that the picture is taken at the maximum allowed shutter speed. Is this an idea even worth pursuing or are there simpler in-camera tricks to achieve this? Thanks in advance!

Hey! I just wanted to try and revive the interest into getting the 70D closer to the crop_rec4k branch.
First of all I wanted to konw if something useful became of the ISO logs I posted a while ago.
Secondly, with regard to the dual_iso experiment I noticed something. In your analysis you said ISO for 3200 and derived is 0xDB, but I just looked at the values and 3200 is 0xb7 for me. Its probably nothing but I thought Id mention it anyway.
Also, are there more line skipping experiments that I can do to try and get the crop_rec modules working?

This is insane. It really works, just like that. Did the test on a gold sandisk extreme 32gb and a 70D. This card now effectively records raw at 49Mb/s instead of 40, resulting in a noticeable bump in resolution/aspect ratio. For those saying they dont see the "real world" results, I ran the test in video mode and mlv_rec was already turned on. I dont know whether turning the cam off kills the overclocking for now, or if running it in video mode was what did it, but this combo worked for me. Also, the test showed a siginificantly different result in photo/video mode (53 vs. 43) and although it only showed 43 in video the card writes 49 continous.

I did notice however that the card got quit warm relatively quickly. Again. This is insane. You guys just made every cam that can run this like 10 times better.

In the higher values The 1080 mode seems to at least be registered as a Dual Iso, but they are just as corrupted looking as the one I posted yesterday. Are there other values I should/could try?

Aaaand here's the log again... gg.

https://we.tl/8JktLBi1AD

Oh yeah, the DNG sequence is:

x83
x983
xa83
..... and so on

In the meantime: Here's the completed test from yesterday. BUT. Something weird happened. I took the remaining test at ISO 400 instead of 800 because I wanted to keep the exposure similar, although I also included the x83 setting as a reference anyway.

This changed the register from x6f ----> to x4b ----> !

I also wanted to include x983 because of yesterday's observations. Here's where the weird bit starts. I wasnt able to take a FRSP at x983.

RAW error.

I wasnt able to save FRSPs up until setting xe83, which let me save one again, xf83 too.

So I thought, well, then repeat the FRSPs at ISO 800. Said and done, Register was at x6f ----> again. But I STILL couldnt save a FRSP. I swear to god I saved one with these settings yesterday and I dindt change anything in the process??

https://we.tl/MJvNGN744B

Ok! so a picture before every log. got it^^.

Ok! So much to learn  !

https://we.tl/ls4TML6XNN

Better?

Here are the register logs in Photo mode, outside live view. Just a minor note in case this is important. Right after startup, there are no registers visible. Since it says "log visible registers" in the menu, I switched to video mode, then back to photo mode before I did the first log, in order to make them visible. I'm guessing thats not relevant, wanted to mention it anyway!

https://we.tl/5KOkgmenc2

Here we go again. Tested the registers x83-x983 that ended on 83 . This is all I had time for today, the remaining ones will come tomorrow. Interesting to note: I installed cr2hdr for lightroom plugin, in all of the registers but the last one (so x983) only the 5xZoom and the FRSP were valid Dual Iso pics (Will try to confirm this tomorrow). In x983, only the 720 does NOT reigster as dual iso. However, they seem a lot more corrupted than lower registers. Full uploaded in case I'm missing something:

https://we.tl/kvdiIomvQJ

ok, then it seems none of the settings with 83 break live view and I redo the test!

As reported, liveview also flickers weirdly pink in x83 setting (720&1080). (does that not constitute "broken"?) Turns to black&white in 5xzoom and stays pink (no flicker) in photo mode.

Ark! Found out myself. Read your previous post carefully and I somehow misread what I should be testing. I thought it was between 83 and 93 but you want me to test all combinations that end with 83, right? I quickly clicked through them and live view is broken in all of them. Is that a bad sign or something we are not concerned with yet? I will redo the test if broken liveview is a non-issue atm!

Ok, I see, too little input from my side. What I did was change the CMOS 0 value from 83 (which I didnt repeat because it was the first set of 4 I uploaded, hence the confusion probably...) to every other step in between 83 and 93.

However, the next value I can achieve by just right clicking the arrow buttons is 84. So the values were as follows:

x84
x85
x86
x87
x88
x89
x8a
x8b
x8c
x8d
x8e
x8f
x90
x91
x92


15 values times 4 DNGs equals the 60 Dngs i submitted. Feel free to now tell me I totally misunderstood the task  haha

Right, here are the other values then. It's always 720/1080/5x/FRSP

https://we.tl/fU1yNdv7Bz

dfort, I'm sure you are right about the testing environment, however, I am so far from working with code I dont even know how to use the command line (heck, I dont even know if that is easy or harder than setting up a testing environment  . )
Thats why for now I thought I'm more of a help taking relatively simple orders and trying to execute them correctly haha. But I will look into it.