Messages

@carlballou: Naaahh, you don't have to use RT at all. Check your mail, I applied the fix (changing the exif:BlackLevel tag to the correct value) to the "bad" .dng you sent me and it is fixed. This is really only a metadata problem, that is, your data is absolutely ok.

For anyone else with a random clip now and then which has a green tint and crushed blacks: (as I've said before) just use exiftool/exiftoolGUI, and modify the value of the exif:BlackLevel tag. For the new value, use the value of the same tag present in a .dng which looks correct and was shot in more or less the same conditions.

Cheers!

@carlballou: Yes, I'm on Windows and Linux. If you want to send me one of the .dng's from the "bad" clip, along with another from one of the good clips (another take from the same scene), I'll take a look at the tags and let you know what I find. I don't know offhand of a way to get exiftool to work on a Mac.

Also, I don't think you should expect exiftool, if it were to work on Mac, to be able to open or process a .raw or .mlv file. You have to extract the .dng's first. Not sure why the ported GUI isn't working for you.

If you do send the .dng's, I'll get back to you tomorrow, as it's already 1am here (Germany). Cheers.

I will look at the two documents you referenced.

I agree the issue should be resolved correctly and fixed. OTOH, the "bad" black level in my bad clip was 2590, which wouldn't appear anywhere on this (short) list, presumably.

If the problem really only occurs every hundred (or more) clips, maybe it's not worth fixing in ML or in camera. Especially if simply changing the exif tag in post fixes it completely.

Waiting to see what @carlballou has to say, and what his "bad" black level is, and if others chime in with the same problem(s), which is (are) also easily fixed.

As for estimating the black level from the raw frame itself, certainly the bad .dng's have a certain "look" which sets them apart: crushed blacks and an overall green tint. Seems like it would be easy to check for both of these in post-processing and offer a suggested fix. But maybe the easiest "check" is just our two eyes when we review the .dng's.

Again, ATM it doesn't seem necessary to insure that ML always writes the correct black level, if it is getting it right 99+% of the time. Right?

@a1ex. Great news.

1) Didn't notice 1st frame corruption in my "bad" clip, so I can't say whether this case applies.
2) Seems like this would cause the problem to appear much more often than it does. I've only seen it in one clip, ever.
3) If we're ruling out 2 and 3, then the problem is probably 1, right? One "good" result of this is that it only affects metadata, and can be fixed in post.

My "bad" clip was shot on 12/24 and unfortunately I do not remember if the memory hack was enabled. To which exact menu item in which ML menu are you referring?

Statistics: How much does the [Exif:BlackLevel] tag vary? Is it always near to 2048 or so, or does it have great variations? If the correct value is always near 2048 (or perhaps near some calculable combination of other parameters like ISO, etc.), then maybe there could be a test which compares this calculation to the "expected" value and offers a choice, maybe right in mlv_dump, to correct the tag.

@a1ex: The essence of this problem (if it is the same one I had a week or so ago) is that it seems to be unpredictable. Nevertheless, perhaps there is a clue in the fact that both of us (that is, @carlballou and I) seem to have "good" clips to compare the "bad" one(s) to. This means that we were both shooting several takes of the same scene. Perhaps there is a time between takes which we should respect and failed to (like stopping recording of an .mlv clip and hardly waiting at all before hitting the record button again, or maybe playing back the .mlv we just shot, then stopping the playback (or not?) with a half-shutter, then starting recording again (while the playback "stopping" is maybe still going on in the background))?

In any case, when I compared a typical .dng from a "good" clip with one from a "bad" clip, using exiftool, the only difference I found was in the aforementioned "Exif:BlackLevel" tag. If @carlballou is able to fix his problem clip with the same procedure, that would indicate that the tag is intermittently being written wrongly, OR that the mlv_dump.exe tool sees something different in the "bad" clip which doesn't allow it to save .dng's with the correct black level.

Let's wait and see if @carlballou's .dng's can be fixed with the same (or similar) fix. If he also finds a "wrong" black level of (I think it was) 2590, instead of the correct level (2046 IIRC), then we will know more.

In the meantime thank you for all you do for Magic Lantern and its users. Cheers!

@carlballou: Take a look at http://www.magiclantern.fm/forum/index.php?topic=7122.msg93340#msg93340. The .dng's I was looking at looked very similar (crushed blacks, green tint) to those from your "bad" clip.

Try the fix I suggested, I think it very well may work. Don't know why it happens, but if the fix is repeatable and makes sense, then this is a good workaround. Once I adjusted the "Exif:BlackLevel" tag, the resulting (fixed) .dng's. looked exactly like .dng's from my "good" clips. Hope this helps. Cheers!

@saofaihp: Hmmm. I tried it on my 550D with the kit lens, and I see what you mean. You hear a clicking sound, like the aperture is changing, and the LV does seem to change its brightness subtly, perhaps in both directions. But to test if this has something to do with the exposure, I did the same test with the lens cap on, and I still hear the clicking. I have not noticed the aperture value in the ML display changing in either of these tests. Not sure what is going on, but perhaps it does in fact have something to do with the lens. Since the LV (when the lens cap isn't on) does change a bit, it seems like the aperture is changing (because of the three variables ISO, shutter speed and aperture, the only one which involves a mechanical change should be the aperture's blades moving in or out) but apparently not enough to cause the displayed f/stop number to change in the display.

Anyone else want to weigh in on this? Is this what one gets for using cheap lenses? Anyone with L-series glass having the same symptoms? Cheers!

@saofaihp: Apologies if you already know this, but some zoom lenses do not have a constant maximum (i.e., smallest F-number) aperture throughout their zoom range. For instance, with my 550D (T2i), the kit lens is an 18-55mm lens with a maximum aperture of 3.5 (at the 18mm setting) to 5.6 (at the 55mm setting). So if you are using anything more open than an f5.6, and you're zooming from 18mm to 55mm, your aperture will change, even though all your setting are set to manual. The lens cannot help it, its maximum aperture is only 5.6 at 55mm.

That's why sometimes you don't see it happening: if you are using an aperture of 5.6 or smaller, you can zoom in and out at will and your aperture won't change.

Cheers!

Als het u blieft: English please (or at least a translation)... Cheers!

@g3gg0 (again): Again the principle of "if you formulate a question clearly enough, you almost have your answer" applies. Pasted the header (Addresses 00000000 - 0000002B) of one of the "good" audio files over the same addresses in the "bad" audio file and it worked. FYI for anyone with a similar problem (shooting with mlv_rec and mlv_snd and you have a crash or skipped frames, resulting in an error message about a possible corrupt .wav file). Cheers and I hope TLDR didn't apply too much...

To all ML users trying out raw with sound: I was shooting a scene with my 550D, using mlv_raw and mlv_snd. One of the clips turned out to have an ugly greenish-black tint over all the .dng's, even though I didn't consciously change any settings between the various clips of the same scene. After I tried and failed to correct this in ACR (Photoshop/After Effects), I thought of using a more scientific method. Using Phil Harvey's exiftool (Google it), I compared the metadata of a .dng from a "good" clip to the metadata of one of these "green-black" .dng's. The only difference I noticed was in the data tagged "Exif:BlackLevel", which had a value of 2046 in the "good" .dng but 2509 in the "bad" clip.

I used exiftoolGUI (Google it) to change the value of "Exif:BlackLevel" on all the "bad" .dng's to 2046, and the problem was solved: the .dng's now looked exactly like ones from the other clips I shot of this scene.

Again, I don't know whether or not I did something to cause this error, or whether it will just crop up from time to time. But if you have this symptom (.dng's with a crushed-black/greenish tint), give it a try. Cheers!

@g3gg0: During one of my first recordings with mlv_snd, my 550D camera locked up (got a "busy" text, sorry I don't remember the exact wording) and apparently the sound file didn't get written properly: I get a "Received AUDF without WAVI, the .wav file might be corrupt" message after all the .dng's are (correctly, it seems) extracted.

Despite this, the .dng's look fine and the length of the resulting .wav file is roughly what one would expect for a 40 second (at 25fps) clip. Of course, it is corrupt, as its metadata indicates "MPEG AAC Audio at 7350 Hz, 28kb/s" instead of the correct "PCM S16 LE Stereo 44100 Hz, 16bps (from VLC player)" as on my other clips.

Question: is it possible to rescue this .wav clip by inserting a WAVI block into the .mlv file, or by hex-editing the .wav itself to correct the header? [Update: SOLVED! See two posts down]
In any case, thanks again for raw with sound, it's a quantum leap in usability and enjoyment! Cheers.

@war10ck: Seriously? The best thing to do would be to get one of these cables (they are not expensive) and test it out! I don't have a 5dIII, but I can connect a cable from my 550d to an HDMI-equipped monitor and definitely see the live view. Of course on my camera, HDMI switches to 480p or something when I hit "record", but I believe on the 5dIII this is not the case. Whether or not you will see the live view picture when you are shooting RAW is something I don't know. But again, just get the damn (!) cable and try it! Cheers!

@g3gg0, andy kh: sound recording works on 550D!

Steps I took:
- Downloaded latest (22Dec) nightly build for the 550D, also your mlv_rec.zip file from the first post of this thread
- Installed nightly build on my SD card by simply copying it over the existing files
- Extracted mlv_snd.mo from the .zip file and copied it into the MODULES folder on the card
- Enabled mlv_play, mlv_rec, and mlv_send, rebooted to load modules
- Enabled "MLV Sound" in Audio menu
- Recorded a short (18 sec) clip (using mlv_rec, obviously, and not raw_rec), which was called M22-1151.MLV
- Clip played back in camera, created a file M22-1151.IDX
- Tried to get mlv_dump (also from your mlv_rec.zip file) to work, but it kept giving error message about "Missing header"
- Renamed index file (created in camera) to M22-1151.IDX.bak and now mlv_dump works with following command (assumes a copy of mlv_dump.exe has been copied to C:\) :
        C:\>mlv_dump --dng "E:\raw tests\20131222\M22-1151.MLV"    ## replace the path with YOUR path to the .MLV file
- After this the typical processing with Photoshop CC (for ACR, synchronizing all .dng's to the selected settings), then After Effects CC -> Adobe Media Encoder to render as H.264 .mp4 file

I did notice that the sound file was a bit longer than the .dng sequence (I was shooting at 25fps): 19.00 seconds vs. 18 seconds, 20 frames for the video. I simply assumed that the starting points were in sync and the sound file cut off a bit later than the video, and that seems to have been a correct assumption, although a longer (few minutes) test is in order to check this thoroughly.

Very nice that we have sound with raw now, excellent work! Cheers...

@ItsMeLenny: Yes, that's the confusion. 45mb/s is 45 MegaBITS per second, which is less than 6 MegaBYTES per second. The SD card limit is about 21MegaBYTES per second. Probably the bitrate viewer you used to check the average "bitrate" shows you just that, not the "byte"-rate.

Cheers!

@buffalohill: the short answer is "because the camera does not have enough computing power to do any processing on the raw video before writing it out to the SD card. A conversion to monochromatic is not a matter of simply chopping off bits, and according to the devs at this point in time, even that (i.e., dropping the raw bit-depth from 14 bits to 12 or 10) is not possible." Cheers!

@all except for apefos: Did I call it in Reply #46, or what? What, right? Cheers!

@apefos: "Doubting" Thomas, right? Clever. @dmilligan and others: maybe it's best to stop responding? You seem to be just encouraging him  Cheers!

Hahaha...LOL! Touché....Advice and concent...Cheers!

@fauxto: And you are......? Why don't you try answering your critic, whose criticism you requested. By the way, it's hard for a rational human being to disagree with anything the critic wrote. What exactly is your point with this film, if not what 5D3Shooter wrote? The film looks and sounds terrific, by the way, no question about it.

Pink present
Windows 7, 64-bit
550D
raw2cdng.1.2.0

Premiere opens CinemaDNG's from the Ikonoscop, for example, without the pink issue.

@maxotics: I think what Andy600 meant is not that the resolution 1280x720 can't be recorded, but that there is no 720p mode (i.e., no Canon-firmware-selectable mode that, instead of recording 1080p@25/30fps, records 720p@50/60fps). Selecting this mode in the Canon firmware, on cameras which have it, like the 550d (the only camera I own), and, I believe, all newer cameras, is the only thing which allows LV to be updated at the faster frame rate. Since ML raw is nothing other than "captured" LV video, the 50D cannot do the faster frame rates. At present, there is no obvious path to 48/50/60fps on the 50D. Devs and admins, please feel free to comment if I am incorrect! Cheers!

Devs and Admins (nanomad?): Apologies in advance if this is posted in the wrong thread. According to the "Nightly Builds" page, the build for the 550D for today (17. Oct.) failed. Just in case no one else has reported this...don't shoot the messenger! Cheers...

@Grifter: With all due respect to 1% and Marsu42, it's not entirely clear to me that the data isn't still on the card. Just because the camera may have used the same name (209 or 210 or whatever) doesn't necessarily mean that it wrote the 209.dat to the exact same location on the card. It may have, it may not have. Of course, the more you used the card after this event, the lower the chances that the invisible (i.e. deleted but not erased) data hasn't been overwritten. If it's really important (and you more or less stopped using the card when you discovered the problem and haven't written to it since), try to clone the card (that is, make a copy, bit-for-bit, of the entire card) with some software (not sure what that might be as I haven't had this problem...yet) and then research the data recovery possibilities. If anyone disagrees, please chime in. Cheers!

@Thrash632: Would you mind please updating the title of this thread to read "DNG to ProRes questions (422 vs 422HQ vs 4444)". There is, as has been stated, no such thing as ProRes 442 nor ProRes 444. I only ask you because it is my understanding that only the author of the thread can rename it. If this isn't true, please just disregard my request. Thanks.