Keep calm and reverse the malware!
Server issues | Builds page | @autoexec_bin | IRC: #magiclantern
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.
I was able to narrow it down to Raw Magic 1.2.2. (MacbookPro Retina mid 2012 and MacPro late 2013)Patrick, this should obviously not be happening. If you wouldn't mind contacting me directly, I'd like your help to get this resolved.
You indeed do good work, but the negativity and name-calling is really not something I want RAWMagic users exposed to.
As far as I'm concerned, Thomas Worth has ignored all reasonable requests by the development team, and now expects the development team to assume his application abides by the GPL, based solely on his word. Support for his applications should be immediately ceased from these forums.I have not ignored any requests. In fact, I went to great lengths to try to appease the ML team. Anyone who reads this forum can figure that out.
Therefore, I suggest enforcing GPL compliance on all the postprocessing apps based on ML command-line tools.As stated previously, RAWMagic is not based on any ML command line tools, nor does it require any GPL code (either linked to the application or calling a separate binary) from the Magic Lantern project to operate. Its core functionality comes from 100% proprietary code, just to be clear. It is not a "derivative work." Far from it.
It relies on my GPL code to do its basic functionality.If one converts RAW or MLV files with RAWMagic that don't suffer from the vertical stripes issue, no GPL code is employed whatsoever (external binary or otherwise) since vertical stripes correction isn't needed. So no, basic functionaity does not rely on GPL code. I assume that's the code you are referring to.
I was wondering, since Premiere Pro CC 2014 now supports 5D3 Raw video, what is the most efficient workflow for editing 5D Mark III footage in PP?RAWMagic (paid version) should not be producing green CinemaDNG files. I spent a lot of time making sure the CinemaDNG files from RAWMagic render properly in Premiere CC.
I just tried to drag the raw files from the 5D into premiere pro and that didn't work. Also when I converted the footage using RawMagic, but all of the footage appears green.
Which color grading program should I learn?Resolve. Don't waste time thinking about this. Just go download it now and start learning it.
Instead of copying the source or object code into an app (like Thomas Worth's)RAWMagic does not contain any GPL code. This is a misconception.
One of the benefits of GPL is that it protects the customer. Suppose I became dependent on Thomas's tool, but then the GPL code were to fix a bug that I found desirable (or even if MLV format changed), all I would need to do is build a new shared library, swap out the one that RawMagic uses with that one, and as long as the code syntax and semantics hadn't changed, I'd be good to go.You can indeed do that now.
I'm not a lawyer, but isn't this shared library approach permissible in GPLv2?From what I understand, no. The code is still executed within the main binary, so this doesn't meet the requirements. A separate binary could be implemented, itself compiled from GPL code, which is what I've done with RAWMagic. This separate binary must itself be open source, of course.
Yes, I'm fine with commercial programs that are also free software, working with ML file formats and being supported here on this forum.
I'm also fine with proprietary software (aka closed source) supporting ML file formats, but if they want to make a profit, that should come from their own code, not from a closed-source modified version of my code.
the simplest solution is of course corrective action on the part of RareVisionAlready done.
RawMagic seems not to be a good choice now because it doesn't support all a1ex and other coders' work.There is no code in RAWMagic written by anyone else but me, save of course for the usual C and Objective-C libraries that you're forced to use if working with the Mac OS X API. Vertical stripes correction is implemented, but RAWMagic uses an external binary (which itself is GPL'd code) to apply it. This causes a performance hit, but is necessary to maintain compliance with the GPL and frankly, done out of respect for the ML developers.
I disagree, ACR is the only way to get the best and most acute results .This isn't necessarily true. I'm fairly sure ACR can't account for the curve baked into footage from Blackmagic cameras, for example. So results from ACR on Blackmagic footage won't be as accurate as Resolve.
Resolve still can't debayer ML Raw right at best its a big compromise ,Can you cite a specific example where Resolve can't debayer Canon/ML footage properly? I'd like to see this if it is indeed a problem. I haven't had a problem. I believe Midphase uses Resolve, so perhaps he can chime in.
It you per-grade with ACR in A.E. I find the workflow is faster in the end.reddeercity, with respect it sounds like you're not as up to speed as you probably should be with Resolve. Any professional colorist will tell you Resolve is one of the best tools for finishing. The only people I know that would even suggest color correcting in After Effects aren't colorists and don't know Resolve. I'm not saying you're one of them, I'm just saying in my experience those are the types that recommend an AE workflow. Furthermore, I have worked as both a visual effects and post production supervisor on feature films, and know both pieces of software well. I can say, without hesitation, that After Effects is the wrong tool for color correction and finishing. It is excellent for motion graphics and visual effects work, and I use it extensively for both. I wouldn't consider using it to color correct anything outside of matching elements in VFX compositions. Yes, technically you can use it for color correction. But then you can also write C programming code in Microsoft Word.
I done the resolve workflow & find it not faster just more convenient and you still
have to spend the time to grade ,where as per-grading . Bulk of you grading work is already done.
Let face it we are working with raw with photographic color space not video, so you must treat it as such and prepare it properlyYou should choose a workflow that suits your needs, but it's a bit shocking that anyone who knows both Resolve and After Effects would prefer After Effects. I highly recommend you spend some more time with Resolve. I think once you get more accustomed to it, you'll find it's much better.
to enter in the Video color space. There will always be short cuts to quality but can you live with the results , personally I can't .
Just my two cents .
In the long run, ACR is not a good solution.Midphase is right. Don't waste your time with ACR. It uses an extremely slow, CPU-based high quality demosaic algorithm that does not work well with moving images. Besides, After Effects is notoriously slow at everything. While it is a fine app for compositing and VFX, you pay for its excellent flexibility by giving up performance.
So in order to bypass long rendering times I can edit directly dng sequences and render only the final cut. Premiere CC only on a computer with dedicated GPU?Yes, and the media on a disk array or an SSD, ideally.
Very HDD space demanding at the moment if you are working on multiple projects and probably not convenient for me. Shame encoding of these sequences still takes so much time.I know what you mean. If you do get around to encoding them to ProRes, it'll open up some options for editing and other work since the computer has a much easier time dealing with ProRes footage versus DNG sequences.
So from reading this thread, Premiere (not AE) has GPU-supported encoding and should thus run faster?Premiere has a GPU-accelerated debayer engine. This will let you play DNG files back at normal-ish frame rates. What do you mean by "encoding?" Do you mean saving to a different codec/file? All of that is typically not helped by the GPU.
I'm not sure about CC, but as far CS6 goes no media decoding is handled by Mercury Engine, not even h264 or AVCHD where cards contain hardware accelerators for such tasksAdobe don't maintain their own H.264 decoder. They use MainConcept's under license, which is a shared library and runs on the CPU. "GPU," by the way, isn't a magic word. From what I understand, some types of math are just not a good candidate for GPU processing. The math used in codecs like H.264 and REDCODE (JPEG 2000) are examples. That's why special hardware DSPs have been needed to accelerate these codecs. As an example, a typical smartphone SOC has a GPU and a hardware H.264 decoder. Why not just use the GPU? Doesn't work that way, apparently.
So, while the sensor and LiveView tasks can go to 40 fps, the bottleneck seems to be elsewhere (even the extra load on memory bus caused by fast CF writes can be too much).I tried with a fast SD card (I originally tried with CF), but got the exact same result. It's only at 40.000 fps the corruption shows up. And it shows up in the first frame or two. It's constant corruption throughout the entire video, not just at the end because recording stopped due to slow media. Every other frame rate (less than 40) is fine. Can you confirm that you were actually able to capture at 40 fps without corruption, whether to SD or CF?
