Messages

I have tried and oh, so many times I have tried using that "t ia2 -exp lock 1/n" command in a ash-script. But So far I have found nothing that even remotely looks like a locked exposure. Am I doing anything wrong? I put that command in a autoexec.ash-file and load it into the root-folder of the card but nothing seems to be happening.

When I tried one of those "Take a pic and then shut down"-scripts those worked. But it just seems to refuse to do exposure-lock.

So far what I have deduced is that it might run the scripts in a sheltered mode. and once the script is done running, it resumes default autoexposure-mode. So a single-line script might be enabling the exposure-lock and then immediately after that (since the script is done) it resumes autoexposure.

I have tried to do a script that takes a pic and then locks exposure and then starts recording for 1000 sec... but that just got my gopro to freeze up in an eternal loop until I pulled out the card and battery and with a separate card-reader I had to delete the ash-script from the card before the GoPro would start working again...

So I'm stumped. I have no idea what I'm doing wrong since so many places are referring to that command as a working method. But I have yet to even see any examples that shows it working. Let alone making it work anything like an exposure lock myself. I mean. It couldn't be that all these people have no idea what an exposure lock is supposed to do, could it? That just sounds too strange to be the case...

A couple of thoughts.

-I understand the reasoning behind going module-based... but  I ger the feeling that we could cut down on a lot of redgundant posts in  this thread if someone kept an up to date patched firmware package easily available for thosr that just want to fudge around a bit with RAW recording... and...

- Also in an effort to keep the redundancy down... why not make a real and updated FAQ in the first post. And there we could have the ready-to use firmware package at the top. And also keep it updated with known resolution-, framerate-, crop-mode- combos that does and doesn't work at the moment.

- And a final thought. At least I would appreciate if statements of resolution would be accompanied with their aspect ratio.

Oh. Has there been any work on trying non-square pixel recording? I mean. If it turns out that the highest resolution possible for continuous raw is in 1.5:1 or something like that. We could maybe sample from a 2.4:1 surface area and squeeze the image into the 1.5:1 recorded image using some funky Custom photosite-sampling setting. This would ensure maximum image detail even when not going for 1.5:1 aspect ratio images since we would not be cropping out any pixels. Just unsqueeze them in post. And if we get full 1080p recording we could use the same methodology to record 2.4:1 sensor area on 1.78:1 image area and end up with 33 %  oversampling when doing renders into a 1920x800 sequence in post...

You just need to read the first post of this thread.

Which is what I did... and once more I read it just to be sure I wasn't misreading it. After reading your reply.

So I therefore take it that it is as I have understood it. That somewhat of a burst mode is available which can be used for a couple of seconds. If, that's the case, then a simple "yes" would have sufficed...

But maybe a framerate override and a further tinker is needed before continuous recording is unlocked

Why did I ask? Well, the first post, which I was referred back to didn't really state this clearly. I came to this conclusion by reading a lot between the lines and implementing quite a bit of other results of research from the myriad of posts growing every minute. I asked it in this thread since it's supposed to be the one about 7D RAW recording development. But the first post says that RAWrecording is not yet available but in the very next couple of posts I see test-videos of the very same feature. It did't match up so I wanted get it clear. That was all.

Now, back on topic... I'll probably wait a while to see the major kinks beaten out of the codes, and a consice set of  instructions for what I have to do, what modules are needed and how they are to be installed are posted on the main magic lantern webpage. Because without that I wouldn't dare risking bricking my 7D because I patched the firmware the wrong way so that the module was incorrectly parsed. Slim risk, I know, but reading the posts which ends with declarations of uncertainty if the writer remembered the procedure correctly makes me wary. Especially when parts of the procedure is scattered on the forum.

By the way. If the same photosites are used when RAW-bursting as when recording h264 as usual, then I'm pretty sure that the VAF-7D will do just as well. Since the VAF doesn't know what you are recording with. Though, when recording in 1:1 crop the VAF will probably only do harm since the gap between photosites are just about eliminated and the anti aliasing filter that's already on the sensor is already built to tackle those conditions. So using the VAF during crop will probably just kill detail that the sensor would handle just fine on its own.

Or why not just drop the guys at Mosaic Engineering a mail asking about it. They seem like friendly folk when I asked them about mitigating the close focus alterations that the VAF induces. And I'm sure they will be able to make much more educated guesses than most of us as to what this RAW-hack might entail combined with their product.

So, just to get things straight, RAW video shooting on the 7D is not yet available in experimental form. What is available is some form of silent picture shooting, that just basically bursts pictures as fast as the card can allow using reduced resolution compared with full more than 10 megapixels per image? This can be used as a simple image sequence but the fps isn't reliable?

I'm sorry if I'm being ignorant, but I've spent the last day sifting through threads where some post state that it's not yet available and some posts even showing test-videos. So things just seem to be a bit contradictory.  Is there a single thread that I should read to get up to date? Because, right now I have like ten threads open in different tabs in my browser with multiple dozens of pages in each. I'd be happy to read up on the subject, but I feel like I don't know where to start, to keep it relevant to the research.

I thought so... I'm actually surprised at how few camera-makers would consider using tricks like those. 

Reading the number-crunching that went on after my own crude crunching made me think about something I've been looking at for some time now... but it does require us to get into how it reads off the sensor. Which may be off-limits for firmware. It's basically a feature-request. But I just need to brain-dump a bit.


Either we maybe could lower the amount of pixels to Scope (1920x800) to lessen the load of the encoder to enable 48fps or the like without increasing the amount of bandwidth per second (by lessening the amount per frame)


Or... this might be fun. Non-square PAR readout. If can muck about with how the image is read from sensor. We could possibly use full 1920x1080 for a 2.4:1 area. Gaining a bit in vertical resolution when we later squeeze it down to appropriate size with vertical oversmpling. 0.67:1 PAR if I understand it correctly... or maybe it's just 1:1.33 PAR.


Or we could do something similar to get a 4:3 area recorded to the full 1920x1080. It probably would gain a bit in vertical resolution after scaled down to 1440x1080. Or full 3:2 sensor readout to 1920x1080.



---
So far so good anyways when it comes to stability though.

I'll probably not go much higher than 100Mbps if given the option. Mostly because of storage-issues if anything.

at what point does the bitrate become redundant considering that what we have to work with is 4:2:0 8bit?

3x8bit=24bit per pixel
1920x1080 is 2 073 600 pixels


2 073 600 x 24 = 49 766 400 bits per frame


49 766 400 x 24 fps = 1 194 393 600 bits per second... roughly 1 gigabit per second when in totally uncompressed mode. So with 100Mbps we get around 1:10 compression compared to the 1:20 that the standard can max out to in 50Mbps...

If my math is correct, that is, of course.

But at what point does the data start being redundant? I've seen some cameras hack out to 300Mbps. how much difference is there?

I mean.. like when they scan film... at some point, the resolution is redundant and all you're doing is recording grain-structure. Sure, I can scan Super8 in 8K... But it won't look that much better than a 720p scan since the grain is so big... for example... Or is it that it doesn't truly become redundant until we record 1080p with a 1Gbps codec?

Soooo... am I reading that right when I say that it's analytics of a video that is variable bitrate with average bitrate of around 100 Mbps and maxing out at 200Mbps? sounds interesting... would like to see example videos and how we can use it...

Anyways... Sounds awesome.

if this has been answered already i'm sorry, but i can't seem to upload the ML file to the root of the camera. is there any specific reason why this is happening? both firmwares seemed to have installed to the camera just fine but this is the only thing holding me from being able to get magic lantern.

Looks like you are using the 7D as a card reader. If that is so, then the behavior is expected. The camera will only allow VERY limited accessability to the CF-card. And writing weird folder-structures(as we have to with ML) isn't part of it. The only way to install ML right now is to use an external card reader (not the camera) to write the files needed to the card.

Has anyone tried creating custom cropmarks for ML?

I created some custom cropmarks and if I load them on ML, it would freeze the camera. It would lock up, and the shutter will fire, but the camera tries to write for, like, forever. (the red LED flashes on). Turning it off/on again doesn't work, had to remove and reinsert battery.

I'm not sure if it's ML or my cropmarks. I created them by opening an existing cropmark in photoshop, edited, and save-overwrite them to ensure the same encoding, etc.

I can't seem to find the attachment option (if it's enabled at all?) so I uploaded them on mediafire: http://www.mediafire.com/?2b8zs7eilb2exp9

I've also made sure that there's only 8 cropmarks on the card. I dunno if that matters or not, but still..

I tried that route too, but ended up with large pink blocks in the image. So instead I followed the guide at http://magiclantern.wikia.com/wiki/Cropmarks and made sure to always end by applying the custom palette provided on that site and then making sure that it's saved as non-RLE-compressed 8bit bmp.

My tip would be to really follow the step by step guide.

Once, it gave big areas of pink that way too. But I found that I hadn't used pure black for the black area that turned pink.

Also, make sure that you only have 9 crop-marks at the most loaded in the folder. My ML refused to load otherwise.

by the way. it seems that the resolution in both the crop-marks and some of the menu-backgrounds don't really match the display-resolution. When trying the cropmarks that comes pre-loaded that has a grid with every other pixel transparent and pure black, it'll give another pattern when displayed on the LCD. Also. When using crop-marks that use single-pixel lines, some of the lines won't render on screen at all. So far I have noticed this with mostly horizontal lines. They seem to get stuck between pixels so to speak. I have worked around this with my own crop-marks by making sure I don't use lines that are less than 2 pixels thick. Is this normal or should we be using some other resolution when creating crop-marks?

[Bug:]

Installed, yesterday, here in sweden on a 7D bought from Japan and using the american Firmware provided here. So far, these are my notes:

• - loading from card is a bit awkward, but expected until later releases. Better that, than having my camera bricked because of prematurely editing the flashed software
  
  - Speaking as a new ML user... the control-scheme in the menu-system is however VERY confusing. Loading menu from the trash-can is understandable, I guess you needed a button that normally does very  little else during live-view. But then in the menu, I sometimes pres Set to change settings, sometimes I have to press Q-menu. And there's no indication other than I have to try the buttons. And the normal menu somehow engages some kind of "hide items" mode. But first dozens of times I pressed it I thought it was a bug. Because the screen would suddenly get a weird pattern over itself and then menu-items would dissapear. I know I'm a newcomer and this feature is probably well thought out... but... I think you would gain a ton of points in usability if the control-scheme in the menus were at least consistent. Or if it was possible to just disable the hide-menu mode completely
  
  - An alpha release is there to just release a working copy to see the problems people find. If it had all the main features, it would be a beta release. Right now they're just letting us test to see if all of our combinations of hardware and shooting-habits are working properly. So complaining that it's "premature" is missing the point, to say the least.
  
  - Bug: Once, when I was playing around today with playback the crop-marks went funky when returning to live-view. It was off-set vertically by a small amount of pixels and left the remaining area transparent. I where using a custom crop-mark made by myself and after pulling up the ML-menu and then closing back to LiveView it went back to normal. I haven't been able to recreate the bug since then.
  
  - ML loads fine with the third party chipped battery bought from LAcolor. And my Canon original too of course. Won't load when batttery is down on red. But that's expected
  I think the camera runs a little warmer. But I'm not ruling out me not noticing before and I haven't been using it as constantly as I have now with ML loaded.
  
  - I am a bit confused. For me, the audio meter is running just fine both in LV and recording...
  
  - first times I launched ML, I had a ton of crop-marks in the folder. I couldn't see all of them but it loaded fine otherwise. Then suddenly it started to complain about it being more than 9 cropmarks and failed to load. I got rid of the unneeded cropmarks and there's no problems with that now. Just odd that it didn't complain at first

Other than those, I am extremely pleased with this thingamajigg. If this was only custom-crop-marks and LV-contrast&Saturation adjustments... I would be so happy. I've been waiting for those two ever since the camera came out! And later, when it's released for real... with the bootloader properly coded... I'll be so much more happy still.

And there's also a couple of features present that confuses me a bit, but I'll be reading the documentation on those and won't bother people here with it.

Again. Usability could need some work, but I love the early results.

[edited post for readability   ]