Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Thomas Worth

#26
The Tokina 11-16mm is a great zoom, and very wide. I shot a video with a rehoused one in PL mount on an FS700 and it looks awesome. In fact, I cut between the Tokina and a Zeiss 100mm prime, and the Tokina looks every bit as good to me. It's only for APS-C cameras, though. A friend just shot a feature and used the Tokina quite a bit. There's lot of low light stuff in the movie and at f/2.8 it's not unreasonable to shoot run-and-gun night exteriors with it.
#27
I generally prefer zooms. There's hardly any difference in quality these days. A crappy prime is still worse than a great zoom. I have some "fast" primes that look terrible near their max aperture. On the other hand, my Nikon 80-200 looks awesome at any stop.

The only downside to zooms as far as I'm concerned is speed (max aperture). You won't find a good 35mm format zoom that will open up more than f/2.8. There have been times I've wanted more light, so I switched to a prime. Canon has some good, cheap primes that will give you a sharp image at f/2. The 50mm f/1.4 and 85mm f/1.8 are fast and look great. Good luck with focus at those stops. ;)

Oh and I wouldn't bother with "kit" zooms, or ones with a variable max aperture (e.g. f/3.5-5.6). They're okay for a beginner, but not useful for professional work unless you're on the sun.

Quote from: Midphase on July 27, 2014, 04:55:06 AM
if you're on a film set, you'd be hard pressed to find a DP who doesn't favor primes over general purpose zooms.
Things are changing. I wouldn't be surprised if more and more DPs start requesting two zooms per camera and that's it. Check out the Fujinon 19-90mm T2.9. A DP friend used it on some gigs and loves it. Canon also make some nice cinema zooms, a 15.5-47mm T2.8 and a 30-105mm T2.8.
#28
Tried that, but no luck. Same thing. I'm assuming this has been tested to work at 40.000.

By the way, I'm running Canon firmware 1.2.3. I compiled from the 5D3.123 branch. Has 40 fps been tested under 1.2.3?
#29
Quote from: dmilligan on July 14, 2014, 11:08:37 PM
have a look at raw_video_rec_task() in mlv_rec.c

All these files are always created before recording starts (so that they can be used as soon as needed during recording). At the end of recording they are cleaned up if not used, but if recording stops unexpectedly they are not. This appears to be by design.
Thanks. I'll have RAWMagic check for these files and ignore them if it finds them.
#30
I see that with the latest build of ML on a 5D Mark III, I can FPS override in 24 fps mode to a max of 40 fps. This is great, but when I set the FPS to 40, it records with mega-ultra-corrupted frames. However, if I back off to 39 fps, it records just fine. Am I doing something wrong? Did I fail to read something about this? Is there anything I can set in the camera to make this work at 40.000?
#31
Check this out:



This happened when recording stopped (on its own). I don't know if this was due to a card issue or something else, but there ya go.
#32
Raw Video Postprocessing / Re: MLV to CDNG Mac?
June 20, 2014, 10:12:04 PM
Quote from: steffenhaldrup on June 20, 2014, 08:46:02 PM
But it's still pink? I don't understand why.
RAWMagic DNGs from MLV files shouldn't look pink in Premiere. What version of RAWMagic are you running?
#33
Quote from: sergiocamara93 on June 20, 2014, 04:27:14 AM
there's still pink cast on the highlights (disappears with chmee fix)
DNGs from RAWMagic work fine in both the old and new Premiere until you adjust the exposure using the new Lumetri controls. Once you drop the exposure, the pink highlights show up. Can you try this and see if you get the pink highlights? The footage must be overexposed for this to work.
#34
Based on my testing, the new update still causes blown highlights to come out pink. You can test this by importing an overexposed CinemaDNG sequence and underexposing the image using the "Source Settings" exposure control. As far as I can tell, this only occurs with overexposed footage.

Oh well. :'(
#35
Quote from: SiMAN369 on June 05, 2014, 08:50:25 PM
Thanks for the responses. After attempting to open a raw file (4.29gb) with a conversion tool such as RAWMagic Lite, the program says 'No files were added', 'Make sure all of your files are in the proper format', 'If you're trying to add a spanned sequence, you must add all the files in the sequence at once'. This process works with any file under 4gb.
If you have a sequence of files, like this:

M05-1234.RAW
M05-1234.R00
M05-1234.R01

You must highlight them all and then drag the entire group of files onto RAWMagic's window. You can't just drag M05-1234.RAW by itself because Apple's sandboxing would only allow the app to access the first file (the one you granted the app access to by dragging it), which is 4 GB.
#36
Quote from: SiMAN369 on June 04, 2014, 11:51:08 PM
No problem post processing anything under 4gb, but footage over 4gb simply won't work.
Make sure the drive to which you are writing your converted files is not formatted as FAT32. As a 32 bit file system, the maximum addressable file length is 4 GB.
#37
This is a cool idea, but there's really little advantage to doing it in camera (as opposed to in post) if you can't get the motion blur associated with mirror slowing to a stop. In a real film camera, FPS and exposure (shutter speed) are directly linked so by slowing the frame rate, you get more motion blur.

If you really want to do this right, you'll link the aperture wheel to the FPS override so we can hand crank!
#38
Quote from: chmee on May 19, 2014, 07:50:27 PM
DFM, seems a guy from adobe inner circle - told some things about it (it doesnt fit into your argumentation):
"adobe has other supporters than magiclantern" ;)
http://www.magiclantern.fm/forum/index.php?topic=11174.msg110968#msg110968
They are talking about the Canon C500. "CanonRAW" has nothing to do with Magic Lantern. Adobe probably has plans to expand CinemaDNG support. This will help you, of course, and others who write DNG files that currently don't work properly with Premiere.

Adobe will never support Magic Lantern because there's no control over when and how the file format and post-processing will change. This is all up to Alex, and basically he could just hold Adobe hostage and request they GPL the entire code base for Premiere because he writes a combination of file format and post-processing code that must be used together. Adobe makes deals with RED and Canon under the strict agreement that they will coordinate changes to the file format so users won't be frustrated that the plugins are outdated. Adobe haven't had to worry about this with CinemaDNG because they control it.

This is why I am hesitant to write my own vertical stripes implementation, no matter how trivial. The way the files are written can change at any time based on Alex's mood, which may invalidate any stripes correction based on previous methods. Then I have to figure it all out again, under threat of violating the GPL. I'm not interested in playing the cat-and-mouse game for a measly $30 per copy. And you can be sure Adobe aren't, either.
#39
Quote from: Audionut on May 19, 2014, 07:27:25 PM
I'm pretty sure the developers are more interest in the development aspect, and development collaboration.  I think I have read that somewhere, once or twice.
You guys have really have done some amazing work. I may have come off a little harsh in my last post, so I just wanted to clarify that. I mean that sincerely. I understand your position, and I'm fine with it. I'll make it work.
#40
Quote from: dmilligan on May 19, 2014, 06:47:26 PM
You're just grasping at straws now. No user would ever be confused that one particular software gives different results of some other different software. Otherwise, they wouldn't be different!
Sorry dmilligan, but you're way off base here. There is a reason why the ITU and SMPTE exist. There's a reason why everyone uses the same Rec. 709 coefficients in reconstructing YCbCr video to display on computer monitors. There's a reason Charles Poynton wrote a book about it. It's because users need consistent output, and are upset when they don't get it. Any self-respecting software developer would do their best to generate consistent results in a way that users would expect.

Look guys, it is clear you are uninterested in whether or not Magic Lantern is adopted in professional setting. Fine. I'm accepting the fact that you're not going to help. Chmee brought up the point that Adobe aren't interested in supporting ML. Well gee-whiz, I wonder why?!?!?!

Keep in mind I work with professional post-production people in the center of the universe for film and TV. I am creating tools that appeal to professionals. Professionals get paid for their work. That's why they don't mind paying for RAWMagic. They have needs that were not being met by the GPL tools that are available, so I addressed this. Crucify me if you want, but your software is now being adopted by more and more professionals because the reputation of my company is behind it.

You're welcome.
#41
Well, thanks anyway for hearing me out.

This is really too bad. :( With a little help from you with this issue, I think Magic Lantern users could have benefited greatly.
#42
Quote from: g3gg0 on May 17, 2014, 01:00:30 AM
i dont understand why ML devs should give everything for free and people earning money dont have to give something back.
especially if things are so simple.
Not everything, just enough to get usable footage from your file format. I just want to be able to give your users a clean image. Do you think that request alone takes things too far?

The fact is I would be accused of stealing the above code even if I wrote my own implementation. That's why I'm asking you to release it under a more permissive license, so we can avoid this conversation altogether in the future.
#43
Anyone trying to implement RAW or MLV format in their commercial products will need these functions in raw2dng.c to repair the vertical stripes artifact:

add_pixel()
detect_vertical_stripes_coeffs()
apply_vertical_stripes_correction()

You could change the license for these functions to make it more appealing to commercial developers. That would be the only license change to the entire Magic Lantern codebase, just those three functions, to allow a basic image to be correctly rendered from a RAW or MLV file without the GPL threat. Any additional processing like debayering or stuck pixel removal would be a separate matter.

Without these functions, a proper image can't be rendered from a Magic Lantern file without GPLing your own code. I'd suggest something very permissive, like a BSD-style license. That's the only way to not scare off big companies like Adobe.
#44
Quote from: a1ex on May 15, 2014, 09:44:11 PM
If you look at the number of ML downloads (it exceeded 1 million downloads, without counting the 5D3, 7D and most recent ports), you will realize right away that relaxing the license for my postprocessing code would be like saying "here you have the perfect recipe to make a small fortune from my work, just take it, it's all free".
I don't know about that, Alex. Your vertical stripes code (let's limit the discussion to this code in particular) is fairly specific to Magic Lantern, and as far as I see would mainly be used for processing files written by Magic Lantern. The only interest I have in this bit of code is for presenting a clean, correct-looking image to the user.

Quote
Unfortunately for some of you, this is not exactly my intention, and GPL is just a tool to prevent such situations from happening. I could have given this code away as public domain, but I chose to protect my work from being used without giving back.
I'm sure many of your users feel that RAWMagic does give back. It gives back by streamlining many of the workflow issues mentioned by your users, which boosts the value of Magic Lantern as a whole. Furthermore, I am contributing my professional experience as a filmmaker to the project by offering tools that cater to users with professional needs.

And I don't disagree with your decision to GPL your code. You've clearly done an enormous amount of work, and deserve to make that call. But, as this situation demonstrates, this isn't the perfect solution for Magic Lantern as a whole.

Quote
Instead, I'm trying to build a community that does not just consume whatever we give to them, but I want this community to actually participate in the development process, help each other, and share the knowledge. We gave you some free software, we gave you a proof of concept that you found useful, and now we expect you all to take this software at the next level, and let us build upon your work, in the same way as you have built upon ours. I'm quite far from this utopian goal though, but this is the direction I want ML to go.
I understand that, and I agree to a point. But I am getting the impression that the developers' definition of "progress" is strictly how clever you can make the code and not how usable Magic Lantern is to the non-software developer. I think there should be a balance here. What about the ability for users to be more creative, and the resulting content? Is that not a positive result of your work? Just because people aren't fixing bugs doesn't mean they're not being productive in other creative ways.

Quote
Therefore, please give me a good explanation about why relaxing the licensing for my postprocessing code can help achieving this goal.
The vertical stripes code in particular is a key component to getting usable images from the 5D Mark III in the way adopters of your file format would expect. You mentioned you're fine with closed source software supporting ML file formats, which suggests you support commercial software working with your files. Unfortunately, the files straight out of the 5D Mk III aren't 100% usable, and this isn't simply a case of requiring post-processing with a well-established technique (e.g. debayering). No, the files require processing in a way that you understand because your software is actually writing the files. Therefore, it seems fairly common sense that if the files require post-processing to look correct, you'd facilitate that in any way you could to all types of developers, open source or otherwise. Again, I'm not talking about post-processing software that performs general image processing that can be used to "make a small fortune" as you mentioned. This code is fairly specific to ML. In other words, I'm not looking to convince you to relax licensing on your vertical stripes code so I can integrate it into all my products as a general image processing algorithm for the purpose of making money from it. I just want to be able to provide ML users with a clean, usable image. I will happily handle any subsequent image processing from there with my own code.

I'm only asking that you relax licensing on the minimum code required to get a clean image out of your files. If people want to make a fortune off your vertical stripes code, they will. They'll just go download it and use it and not tell anyone about it. I'm not going to do that though, and instead am going to hope you grant the community a more permissive license so we can move on from this issue and redirect our time to helping ML users be more creative.
#45
Well, let me just ask this:

Do you want commercial products to support the Magic Lantern file format?

If the answer is yes, then I suggest relaxing the licensing on the vertical stripes code. The reason is the 5D Mark III files written by Magic Lantern, for whatever reason, have errors in them that need to be corrected through post-processing using Alex's code. This needs to be done to get something 100% useful out of the camera. Releasing the MLV format to the public was a very good thing, but this only gets us 90% there.

By keeping restrictive GPL licensing on this in particular, you're basically holding the image hostage until commercial software developers give up all their code, which they're not going to do. The result is commercial developers are discouraged from adding support for RAW and MLV, which hurts Magic Lantern users for the reasons already discussed in the thread.
#46
Raw Video / Re: Greater than 30fps in crop mode?
April 05, 2014, 07:35:06 PM
Quote from: a1ex on April 05, 2014, 08:12:58 AM
Thing is... we don't know how to change the resolution (we are just cropping what Canon already gives us).
Okay, so then you are reading the full output of the sensor and just deciding which parts to write to the card, e.g. based on the CF card speed? If that's what is happening, then you could window different areas of the sensor. Wait, aren't you already doing that with the white box / joystick control? The "resolution" of the output file would just be whatever resolution you decided to write to the card. Am I in the ballpark here?
#47
Raw Video / Re: Greater than 30fps in crop mode?
April 05, 2014, 04:13:40 AM
Quote from: a1ex on April 04, 2014, 07:50:11 AM
There is a single crop mode, and it doesn't care about what FPS you have set in Canon menu.
Is there any possibility of pulling data off the sensor in crop mode at any rate greater than 29.97? Even if it's at small resolutions?
#48
Raw Video / Re: Greater than 30fps in crop mode?
April 04, 2014, 01:14:39 AM
The problem is the aliasing is so bad in 720p mode that the footage is pretty much unusable. Is there no way to use crop mode when shooting 720p?
#49
Raw Video / Greater than 30fps in crop mode?
April 03, 2014, 05:46:38 AM
I'm working with a 7D and would love to be able to record greater than 30fps in crop mode. Is this possible?
#50
Raw Video / MLV quirks
March 14, 2014, 08:12:59 AM
I'm looking into MLV, and am dealing with two issues at the moment:

1. mlv_file_hdr_t.videoFrameCount is sometimes 1-2 frames more than the actual number of frame chunks in the file. Is this a known issue? Right now, I have to parse the entire file to reliably determine the frame count.
2. Audio is always 5-6 frames greater than the video. If someone can offer a technical explanation for this, I can see about compensating for this during post-processing.

That's all for now. ;)