Canon 6d bulb ramping, Auto ETTR

Started by trphotograpy, February 02, 2014, 07:10:28 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

trphotograpy

I have magic lantern running on both my 5d mkii and my 6D
has bulb ramping now been removed from magic lantern full stop? I notice its on my 5d mkii old firmware but not my 6d.
if I update my 5dmkii will it be removed? its probably the feature I use the most and was totally bummed out it was not on the 6d.

I have tried to use AutoETTR on the 6d to try and have got the same results 2 nights in a row of it failing to do much changing of any settings, I am close to giving up.
its shooting again now (day to night) and from looking at the pictures, its not going well again. the iso for one does not change

I have read that peoples posts about bulb ramping on there 6d, if there a previous build with it in I can download?
it is super easy to use on the 5dmkii

1%

Bulb ramping was removed from ML. I think its turned into the post deflicker scripts.

ETTR is working as far as I can tell, should be used in M mode.

trphotograpy

just brought it back in and another disaster. do I need to change anything so the iso changes? I set it to 200 and it did not change at all

I have set it to all the setting in this thread -

http://www.magiclantern.fm/forum/index.php?topic=5705.0

1%

ISO changes constantly for me. Maybe try a newer version? If you compile try compiling the latest.

trphotograpy

it appears not even the exposure changed, bah
I'll see if there is another version.

trphotograpy

Ok got a slightly newer version but no setting are changing by them selves still when running. should they be changing?

trphotograpy

I am using a manual samsang 14mm lens, could this be the problem?

1%

Heh, are the registers wrong though? Or just not written into meta data (white level)?

Definitely a large difference in a photo taken with mini_iso and without.

trphotograpy

I'm not sure what you mean tbh.
tonight I have tried doing it but with auto exposer on too with a few of the settings tweaked and it seems to have done the job.
does that do the same sort of bulb ramping thing?

1%

I think I replied to the wrong thread.

trphotograpy

a little update, I installed the newest nightly build on my 5d mkii and the ETTR bulb ramping method works a dream and completely different to how the 6d reacts so I am going with the 6d is not quite working yet.

1%

More specifics on what/how is wrong? I'm not a big bulb ramping user

trphotograpy

nothing happens, with the same settings on both for example
as a test. I set up the intervalometer, deflicker and auto ETTR on both.
After each shot the 5d will beep and do all its working out on screen and get the right exposures/levels. (like the old bulb ramping feature) and then the settings will change when I move the camera.
on the 6d with the same settings on, the camera will take a picture and nothing will happen at all. just carry on with the intervalometer. If I move the camera it will all stay exactly the same settings.

mofig

I'm going to try and get around to investigating this, I haven't even tried the bulb ramping yet on my 6D, but it's a feature I would love to have.

1%

Well its beeping and XMP files are being create:

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Magic Lantern">
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Description rdf:about=""
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/"
    xmlns:crs="http://ns.adobe.com/camera-raw-settings/1.0/"
   photoshop:DateCreated="2050-01-01T00:00:00:00"
   photoshop:EmbeddedXMPDigest=""
   crs:ProcessVersion="6.7"
   crs:Exposure2012="+1.38849">
   <dc:subject>
    <rdf:Bag>
     <rdf:li>ML Post-Deflicker</rdf:li>
    </rdf:Bag>
   </dc:subject>
  </rdf:Description>
</rdf:RDF>
</x:xmpmeta>


But I am getting a lot of misses on raw... maybe time to remove the dual iso preview... it got rejected from main and had the possibility of screwing up the image.

mofig

I played around with this for a while tonight on my 6D, and everything seems to be working as it's supposed to. ISO is adjusting, XMP files are being created etc. Not sure what could be up, image review is enabled and such? I do get a RAW error message on the very first picture for some reason, but then it starts working.

a1ex

Quote from: mofig on February 11, 2014, 04:34:33 AM
I do get a RAW error message on the very first picture for some reason, but then it starts working.

This means you may be using the buffer address from the previous image. Sometimes it stays there, but other times it changes (especially once you take a burst).

So, I'd say double-check raw_buffer_intercept_from_stateobj and RAW_PHOTO_EDMAC (printing raw_buffer_photo with a notifybox for example may help figuring out what's going on). Note that on 5D3 there are 2 sync points from the state object (both with slightly different behavior); worth trying both of them.

Took a quick look at TL code and they are out of sync (RAW_PHOTO_EDMAC 0xc0f04808 matches the sync point from main repo - sssCompleteMem1ToRaw - but your state-object.c is using sssCompletePrepareLcdJpeg, which - at least on 5D3 - should be paired with 0xc0f04008).

Marsu42

Quote from: a1ex on February 11, 2014, 06:32:27 AM
This means you may be using the buffer address from the previous image. Sometimes it stays there, but other times it changes (especially once you take a burst).

That also could be the problem for general raw problems - on my 6d/TL the first raw also fails and then is unreliable... I first tried to pin this down to compiler or timing problems, but but alex' explanation sounds logical.

a1ex

This shows how important are these little clues (at first sight you may think they are just minor quirks and ignore them).

At this point I dare to ask you to try the 6D ML code (move it back from unmaintained and update the makefile). At least this part should be OK.

Marsu42

Quote from: a1ex on February 11, 2014, 07:04:17 AMAt this point I dare to ask you to try the 6D ML code (move it back from unmaintained and update the makefile). At least this part should be OK.

Ok, ok :-) ... but I do hope the backports will keep coming, I don't care about bleeding edge video but simple porting of latest modules to 6d (not only to TL) is the key for more people using ML again.

mofig

Hi alex, I just tried with the ML version, and you are correct, the RAW error goes away.

Marsu42

Quote from: mofig on February 11, 2014, 08:22:24 AM
Hi alex, I just tried with the ML version, and you are correct, the RAW error goes away.

Yippee, I'm sold :-> ... I just added another ml fork, will patch in my personal stuff and if everything works I will submit some pull requests for my features/fixes that went straight into TL.

1%

Quotewhich - at least on 5D3 - should be paired with 0xc0f04008).

When I first imported the dual iso preview I tried this reg and got nothing. The raw error started happening when those messages went into ETTR. So the solution might be to just disable dual preview and go back to the old hook. I'll try it both ways again and see if its more reliable as I haven't heard a single person using the preview :)

Marsu42

Quote from: 1% on February 11, 2014, 02:27:09 PMI'll try it both ways again and see if its more reliable as I haven't heard a single person using the preview :)

Thanks for trying to fix this, you never heard of me using the preview because I never got it to work, ever :-p

1%

Weird, it always works for me except now with the first shot having "raw" error. I'll give it a go in a bit and see how both ways pan out.. btw, try io_crypt yet? I got it working but tested password only, not RSA.

So.. interestingly enough... now the register like 5DIII works and the preview does not.