Messages

Also see http://stackoverflow.com/questions/10952689/code-ported-from-one-to-another-language-licensing

I wouldn't even think of it!

So you are going to take for example my postprocessing algorithms (vertical stripes, chroma smoothing, bad pixel fix, dual iso, whatever) and rewrite them in some other language, under a more permissive license, enabling commercial developers to use them without giving anything back.
Will you design those algorithms from scratch? I highly doubt.

Wait.  What?  I thought MLRaw was an open standard, and according to this thread, commercial entities have already done this.  How did they solve these issues?

Isn't one reason you provide a reference implementation is to enable people to create their own implementations?  Yes you don't want people to rip off your work and I get that.

What would you want or not want me to do with regard to these algorithms?  It sounds like you don't want them copied and I respect your wishes.  That seems to mean you want me to write new algorithms.  Anything I come up with I'm happy to contribute back to the reference implementation.

Will I create more algorithms for ML? Why would I do that? To fill the pockets of some third parties?

It's got nothing to do with filling pockets.  I don't believe for a second that Thomas Worth has or will ever have more than a handful of users (no offense).  A million ML downloads?  How many of them unique visitors that are raw video shooters on mac?  If anyone really thinks that they're a big enough user base, someone would have cared enough to provide them satisfactory tools like they have on Windows or Linux.  It's not like they haven't been vocal.  But it's such a small niche I really don't understand the fuss... and I concede the point that even a single 1-penny download is immoral IF it violates agreements.  However people in this community have been very dismissive indeed of their needs, dismissive of Thomas Worth's contribution in providing a UI -- if UIs were trivial, Javascript would not be as hot as it is right now in the job market, and there would be no value in RawMagic.

But forget RawMagic.  My main goal (other than my own selfish desire to write it in a scalable language) is more for the poor guy working at a post processing firm that needs to suddenly deal with ML.  Or a larger entity like Adobe that may want to adopt ML but cannot because of GPL.  Neither of them want to make a small fortune out of ML, it's to support their business processes that currently work fine by not supporting ML.  It wouldn't surprise me to learn Thomas's most active user is himself.

=> you will be sabotaging the ML project, as others have already pointed out.
FYI, ML development is stopped because of this issue.

FYI alternative library development has not started yet.  a1ex, I am asking you, g3ggl, and the community for guidance from you on a potential solution to GPL issues in the context of RawMagic.  I already asked you guys to bury the hatchet with the man but now people are getting dug into their extreme positions and not offering up solutions.  What extreme positions?  Threats to complain to the apple store, threats to remove access to the forum, measures taken.  That's not nice.

I'm sorry to have upset you.  We code because we love it not because we are paid to do it, even if some of us are paid to do it.  I've been coding since I was 4 and I'll be coding 'till the day I die.  If I had to work in another field because there was no money writing code, I would still do it at night.  So make a decision on how you want to proceed and let's get back to doing what we love.

@alex - of course!  Thanks for the input.

I meant it when I said it would be a *complete* rewrite.  It won't be in C or even a language that resembles anything like C, maybe Erlang but more likely Haskell or Scala.  I've already worked out how to generate C libraries from those languages so they are accessible externally.

[reference implementations]

Magic Lantern's reference implementations and end user tools are no platform libraries.
and they are GPLed. period.

whats the problem with it?

I don't want to speak for anyone else but I see no problem.  Your contributions on ML are awesome.

Since they're reference implementations and not reusable libraries for post production, I see an opportunity to improve the adoption of ML in some places where there is currently no innovation. 

@g3gg0 are you cool with this?  This is the time to discourage me, before I have devoted a lot of time

I guess I'd like to build this library with the cooperation of the community, rather than fighting an uphill battle.  And I'm certainly not suggesting it'll be closed-source, just with a different open-source license.  It wouldn't be in defiance of ML, rather, be an enabler of other downstream products, just like ML depends on CHDK.

Reading... http://www.gnu.org/licenses/why-not-lgpl.html this seems like a well-reasoned article covering both pros and cons.  It's maybe not the list I was looking for, but is consistent with @dmilligan's argument, while addressing some of my concerns.  Here's a small list of apache licensed projects: https://projects.apache.org/indexes/quick.html -- there is a huge number of professional programmers that depend on these libraries that wouldn't use them if they were GPL.

Why wouldn't such a company be able to simply implement MLV processing code itself? They have the resources to do 99.95% of the coding, but for that last little bit, they need to use some GPL code??? I don't really think you understand. It's not like MLV processing is patented or something. If you're a commercial firm that wants to process MLV files, there's nothing stopping you.

Well, it's kind of annoying to have to reinvent the wheel.  That's why open source is great

You are essentially volunteering to work for free for people who will turn around make money off of your work and give nothing back. You are basically asking to be taken advantage of. You have every right to do this, but why would you?

For one, I use RawMagic and I don't want to see it forced out of existence by GPL.  For two, being the author of a good library is good for the resume.  For three, because I care about ML's future and GPL post processing code is a barrier to that IMO.

I would never freely contribute code to an LGPL (etc.) project, and I think you'll find the other developers here are probably in the same boat. If I'm going to put my work out there for free, I'm not doing it out of the goodness of my heart. I'm doing because I want something in return: that is other people to come along and add to what I've done, so that I can learn from them and receive the benefit of their work, just like they received the benefit of mine. When you stop using copy-left you completely loose that.

That's true, but in another sense, a more flexible license will allow another class of applications to exist.  I understand the needs of users enough to recognize they want better tools than they want to save $30 by not buying RawMagic.  That is why there are a few buyers.

I recently started a new project MLVFS with an idea I had for a new way to process MLV video.

Nice.  I'm already a fan.  Good work!  If I use it and make changes I would totally contribute them back.  GPL seems like a good choice for you.

I made it GPL b/c I knew I couldn't do all of it myself and I wanted others to help. And they did, and now it's quite mature, supported on all major platforms => in less than a month. I could never have done that myself. LGPL or some other license would not have accomplished that level of collaboration. Some commercial developer could have simply taken my work, polished it, sold it, and then charged me to even use it! And I still would never get to see the code improvements.

I guess it's a good sign that a month was sufficient for people to make progress.  What I'm trying to do doesn't seem like rocket science but raw processing is somewhat new to me.

It's cool that if you make code improvements to have those contributed back.  This thread is about using the GPL to force Thomas to open source ALL of RawMagic, not just the improvements to ML.  I would have liked to have RawMagic's source but I support his right to free software.

I think you have completely missed the point, which is especially sad since you call yourself a developer. Developers who intend to make commercial tools for ML do not need you to make these libraries for them (they can and should simply make their own, they're the ones who are going to be making money off of it after all).

I understand what you're saying, and I don't think I've missed the point.  Your point is that GPL is good in that it encourages contributions.  I understand that and I think ML by and large benefits from it.

I guess I call myself a developer, though I admit most of the code I've written has not been open-source, something I'd like to change.  I still don't agree that commercial tools developers don't need ready-made libraries.  Wouldn't everyone benefit if they shared the library between them especially if that was a supporting/generic part of their business, as opposed to the core thing that delivered them their competitive advantage?

I doubt the ML developer community will want to contribute, help, or use your libraries either, because of the lack of copyleft protection. So who's left? What's the point?

http://www.gnu.org/philosophy/free-sw.html

I'm sad to hear that.  I hope that sentiment is not universal.  We live in a world where ML is not included in consumer-grade post production apps we love, and that's what we could gain by a rewrite.

http://lmgtfy.com/?q=list+of+GPL+software
Completely false. VLC is GPL. Somebody didn't do their homework: http://www.videolan.org/legal.html

Grin.  You are correct.  I did my homework on FFmpeg which is LGPL.

There's the distinction.   VLC is an app.  FFmpeg is a library.  Find me a library is what I should have said.

I've been putting some thought into this and I think making post-processing code GPL is appalling.  I maintain it's a good choice for in-camera stuff, that's dependent on CHDK for the same reason that it's a good choice for the Linux kernel but it has no place running as part of any desktop app.  [Edit: In-camera code is] the vast majority of the ML code base.  How many libraries that are intended to be reused by developers are GPL, and not LGPL, Apache, etc?  That's the real issue here.  Go find me one, a major one.  VLC? nope.  Anything that web apps use? nope.  glibc?  nope.  Hmm, I wonder why that is.

As a programmer that's worked developing software for large studios and video engineering firms, it would be silly to expect for example, an in-house asset management system to be forced to open it's code just because there is that .05% of it that needs to use ML code to pull .RAW and .MLV metadata.  Getting into that kind of licensing battle that you can see in this thread is the last thing any production large or small needs.  Even if you say to yourselves, "no we're not jerks, we would never do that since this feature is such a minute part of their code base," the problem is that the whole idea of a license is to allow people to use software in very specific ways and under very specific conditions.  I want nothing to do with that kind of headache.

So perhaps the most useful contribution I could make is a complete open-source re-implementation of the post-processing code in an Apache license.  There are lots of optimizations I think I can be made in the process anyhow that would benefit the community.

Alright I'm all fired up do do this.  I'm certainly not going to contribute to any GPL code base that could touch the post-production workflow but I hope to work in partnership with and respect for the community in providing tools that liberate developers.  I also totally support the in camera code staying GPL and I would contribute to it if I had something useful to do.

Please post feedback as to this direction and feedback on potential pitfalls and how we can work together to avoid them.

P.S. Does anyone have the MLRaw spec handy for me?  IIRC something was published.  I gather that for RAW, the last 192 bytes has a data structure holding most of the metadata needed to process a file.

@Audionut - you make some good points.  I gotta run but I'll think about what you have to say.

there are commercial developer who contacted us and they even got support and example code they can use freely in their tools.
e.g. mlv.c/mlv.h accessing code at an early stage was given out to commercial tools for inclusion.

Nice.  At first I was concerned that ML was against supporting commercial tools.  It's good to see that's not the case.

i dont complain about the "big ones", tools where reading and processing MLV/RAW is 0.1% of their code base.

That's exactly where it gets tricky.  Just because today, you go after some people for abusing your GPL code and not others that use the exact same code in the exact same way, by your earlier standard, everybody is potentially in jeopardy into perpetuity.  Unless you grant them a different license, of course, but IIRC every contributor needs to sign off on that.  Is that the case?

but re-using our GPLed processing code for a commerical product that does the same as our GPL one is a red rag. (yeah he added a GUI. wow. amazing work)

If that were true, then yeah you have every right to be pissed.  I know the man's been writing post production code for decades and has his own debayer algorithms.

How much code are we really talking about?  I thought raw/mlv to dng is pretty straightforward.

it is about respecting rights and licenses. we did not even receive a earnest "sorry, i didnt think about it", just ignorance and lies.
"no, there is no GPL code", then "i removed the GPL code", no honest discussion, even requests to support ML were ignored.

so our decision is clear: we dont want such tools here.
whats wrong with that?

I see that things have escalated to the point where everyone is resentful.  If he were to come clean about any misdeeds of his past, would that help?  Other than what he's not willing to do (release rawmagic source), what are your expectations of him in terms of contributions?

There are enough RawMagic users out there that find it useful that would like to see the hatchets be buried.  As a developer, I just hope to see a precedent made where he gets treated rationally and with fairness.

Let's separate the free software discussion from the open-source discussion.  Yes, not having to pay for software is great.  Open source software is great too.  They're distinct ideas, though.

I went to a talk by Richard Stallman some years ago where he told an anecdote of a firm he went after for copyleft infringement.  He bought their software which depended on a GPL library.  He wrote them demanding the source code.  He heard nothing for six months.  Six months later, they returned his check with a note from their lawyer saying he was not a customer.

The talk he gave was at a meeting held by a local university, where he promoted the idea that GPL supports those of us who want to make a living as developers.  A common scenario is that you work for a firm building software and they are your customer.  You have only one customer, and you're going to give them your code.  If you want a customer #2, then good luck getting them to pay you since it's open at that point.  Anyway, that's a typical scenario.

The alternative for the firm in question was to release the source code.  They decided they would rather not have Stallman as a paying customer.  Real users weren't willing to put pressure on their vendor to release the source code because they liked the product.  The story basically ended there.

I see a lot of similarities in this case.  If at some point in time there was a version that had GPL, and when someone complained, Thomas Worth in good faith remedied the situation by removing GPL code, that should be satisfactory.  To say it's not good enough sends a message to the world at large not to adopt MLV.  It just seems like an extreme position to me.

My main concern here has nothing to do with the particulars of RawMagic, it puts into question the viability of developing any meaningful post-production workflow for the larger community.  If Thomas Worth faces this amount of hostility, then we'll definitely never see MLV support in any of the nice post-production tools we all know and love.

Also, just because there once existed a copy of software called RawMagic in the universe that had GPL code, that anyone anywhere can demand to have it open is a pretty scary thought.  In his case, it really doesn't seem like he intentionally set out to violate the license and abuse the thousands of hours of work you've contributed.

g3gg0, I really hope you reconsider your position.  The Linux kernel, fair enough, GPL.  Basically every library that programmers use enables programmers to charge for their time.  I like the idea of ML code that runs in-camera to be GPL for the same reason I like Linux to be GPL.  But the post workflow that's supposed to provide convenience for users should adopt a more flexible, programmer-friendly model.

What are the options for well-intentioned programmers who want to work for food?  Let's say I wanted to work for a studio that just decided to use MLRAW on a crash cam for a small part of their production.  If I were to tell them that I had to release any code I wrote for their in-house video management system as open source -- or in the extreme case, their whole platform, I would be out of a job for sure.

There is another way around the previous versions with GPL code.

If you did not buy a RawMagic version with GPL code, you have no standing to demand the source code for RawMagic.

If you did buy RawMagic with GPL code and you still possess it, you can demand the source code.  At that point, Thomas can refund your money and claim you are not a customer.  Then you have no standing again.

I propose a new implementation of the post-processing code with an Apache license.  That would encourage other firms wanting to make life easier for ML users building support for MLRaw.  LGPL is an alternative (looks like FFMPEG uses that https://www.ffmpeg.org/legal.html).  There are probably some pitfalls but there is probably a way where everyone wins if it's done considerately.  Worst case, it would mean rewriting it all, which is a nontrivial effort

Opinions?

Instead of copying the source or object code into an app (like Thomas Worth's), would there be any problem in creating a shared library containing those implementations?  Most of the post processing I do is in bash, but I might like to be able to use a different high-level language like python, ruby, or java (all of which can depend on shared libraries) to achieve a level of efficiency in automation that is tailored to me that I can't get with a gui or bash.  Hell, maybe other vendors like Adobe would produce support as well, if this were more developer friendly.  Yeah, I know, dream on ;]

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.

The reason that's good for the customer is that if Thomas were to copy compiled artifacts into his app, I would have no recourse if Thomas got too busy to produce an update, decided to cut support, or became otherwise unavailable.  If he just depended on a library, I as a customer would be protected.

I'm not a lawyer, but isn't this shared library approach permissible in GPLv2?

If this seems like a worthwhile direction to you, I'd be happy to investigate what would be needed to produce that shared library.  I'll have some time later next week because I'm taking a week off between day jobs

Happy shooting, folks!

Sebastian's article is welcome in that, yes, there are things we can learn from it.  And improve.

I've always been curious... on why the site's name is "cinema5D" -- doesn't the name make you think it's intended to be 5D expert advice geared toward 5D users?  Or DLSR filmmaking in general?

To borrow a term from our marketing friends, I wish the "Brand Promise" of cinema5D would align more closely with ML.

Anyway as to the handling and workflow, I think ML Raw is geared more toward people who actually own Canon and by default invest the time to learn it's quirks.  More than someone used to film or pro gear, or is out of film school where they were trained in Alexa and Red. 

But I think he got that message across to those who need to hear it in the way they'd understand.

Flare?  Did someone say J.J. Abrams 

Definitely accidental in that case.    Someone should start a kickstarter campaign to buy the man a matte box!

This has been a subject of a lot of experimentation for me.

I generally agree that unless you're shooting stills or crop modes, lens resolution/sharpness really isn't a factor since 1080p is such an incredibly low resolution.  Especially considering the detail that all still lenses are engineered to produce on full-frame film.

But there are a lot of other optical qualities that you get from a lens in it's overall rendition like contrast, flare, bokeh.  These differences are apparent if you cut with from a high contrast lens like a Zeiss prime (well, ok, *many* Zeiss primes) to a lower contrast Leica or Canon.   This is especially noticeable with a human subject.  With all of the data that we get in 14-bit raw, yes you can very easily adjust the contrast but those two shots will never look the same no matter what you do.  The point is there are difference between zooms and primes in these qualities.

There is a lot of mention in this thread of new Canon L autofocus glass.  I have the 24-70/2.8L (edition I), 70-200/2.8L (non-IS parfocal), 50/1.4, all EF autofocus.  They don't get used much because it's absurd trying to pull focus with them, I don't like camera-controlled < 10 blade aperture, and the crisp & clear look isn't what I prefer these days, it's too perfect.  All of that convenience is ideal for stills, though.  I hope I'm not off-topic here, apologies in advance...

The problem is that the selection of autofocus zooms that are also parfocal is very slim.  The opposite is true with older manual focus lenses.

I have a set of Vivitar M42 lenses, a set of Russian M42 lenses, a Canon FD set (thanks to EdMika on ebay and his adapters), scattered German, and an assortment of antique lenses for experimental use.  Collecting vintage glass to adapt to ML raw has become something of a hobby.  The only potential drawback is a time investment in finding the right adapters, and any cost you may face if the copy you're buying needs cleaning, lubricating, possibly declicking the aperture, etc.  IMO it's worth it.  I should get my act together and post samples at some point.

Anyway to get back to the OP's question, the # of lens elements of a zoom is large, so in addition to what's been said about how they resolve differently, the flare of a zoom will never look like that of a prime.  You almost never want flare in a still photo, but I see it a lot in film, and it's usually intentional.

Ludo,

Are you preparing for an important day shoot?  If so sure you try end-to-end post workflow with whatever nightly build that you're using beforehand.  It will give you a good idea of what you're getting yourself into.  There are things that can go wrong during the shoot that will ruin your day if you are not prepared.  Just making sure...

mlv_rec is the newer format that supports audio but if at all possible don't use audio on-camera - the recording speed to memory cards is the bottleneck and it'll mean a lower possible resolution.  If you're on a mac, the free version of RawMagic (ML post processing) won't support mlv_rec, only raw_rec, but the paid version is only $30 IIRC.

Compilation fails on OSX Maverick after Xcode was upgraded to version 5.1 on March 10, 2014.

[Edit:] I should have added that ML autoexec.bin and modules compile OK without any issue even after the Xcode upgrade.
compilation fails only for mlv_dump.

Code Select Expand

[ HOST_CC  ]   mlv_dump.host.o
clang: error: unknown argument: '-mno-ms-bitfields' [-Wunused-command-line-argument-hard-error-in-future]
clang: note: this will be a hard error (cannot be downgraded to a warning) in the future
make: *** [mlv_dump.host.o] Error 1

This did not help either:
export CFLAGS=-Qunused-arguments
export CPPFLAGS=-Qunused-arguments

Removed '-mno-ms-bitfields' from modules/mlv_rec/Makefile, but ld was not happy.

MLV_CFLAGS = -I$(SRC_DIR) -D MLV_USE_LZMA -m32 -Wpadded  -D _7ZIP_ST -D MLV2DNG

Code Select Expand

ld: warning: ld: warning: ignoring file ../../src/chdk-dng.host.o, file was built for i386 which is not the architecture being linked (x86_64): ../../src/chdk-dng.host.oignoring file mlv_dump.host.o, file was built for i386 which is not the architecture being linked (x86_64): mlv_dump.host.o

ld: warning: ignoring file ../lv_rec/raw2dng.host.o, file was built for i386 which is not the architecture being linked (x86_64): ../lv_rec/raw2dng.host.o
ld: warning: ignoring file lzma/lib7z.a, file was built for archive which is not the architecture being linked (x86_64): lzma/lib7z.a
Undefined symbols for architecture x86_64:
  "_main", referenced from:
     implicit entry/start for main executable
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [mlv_dump] Error 1

Removed -m32 from modules/mlv_rec/Makefile, no luck either.

MLV_CFLAGS = -I$(SRC_DIR) -D MLV_USE_LZMA -Wpadded -D _7ZIP_ST -D MLV2DNG

Code Select Expand

Macintosh:mlv_rec okumar$ make clean && make mlv_dump
[ RM ]  mlv_rec.o mlv.o mlv_rec.mo mlv_rec.sym mlv_rec.dep module_strings.h *.o *.d *.dep *.sym hgstamp
[ RM ]  mlv_dump mlv_dump.exe lzma/7zAlloc.host.o lzma/7zBuf.host.o lzma/7zBuf2.host.o lzma/7zCrc.host.o lzma/7zCrcOpt.host.o lzma/7zDec.host.o lzma/7zFile.host.o lzma/7zIn.host.o lzma/7zStream.host.o lzma/Alloc.host.o lzma/Bcj2.host.o lzma/Bra.host.o lzma/Bra86.host.o lzma/BraIA64.host.o lzma/CpuArch.host.o lzma/Delta.host.o lzma/LzFind.host.o lzma/Lzma2Dec.host.o lzma/Lzma2Enc.host.o lzma/Lzma86Dec.host.o lzma/Lzma86Enc.host.o lzma/LzmaDec.host.o lzma/LzmaEnc.host.o lzma/LzmaLib.host.o lzma/Ppmd7.host.o lzma/Ppmd7Dec.host.o lzma/Ppmd7Enc.host.o lzma/Sha256.host.o lzma/Xz.host.o lzma/XzCrc64.host.o lzma/lib7z.a lzma/Threads.w32.o lzma/LzFindMt.w32.o lzma/MtCoder.w32.o lzma/7zAlloc.w32.o lzma/7zBuf.w32.o lzma/7zBuf2.w32.o lzma/7zCrc.w32.o lzma/7zCrcOpt.w32.o lzma/7zDec.w32.o lzma/7zFile.w32.o lzma/7zIn.w32.o lzma/7zStream.w32.o lzma/Alloc.w32.o lzma/Bcj2.w32.o lzma/Bra.w32.o lzma/Bra86.w32.o lzma/BraIA64.w32.o lzma/CpuArch.w32.o lzma/Delta.w32.o lzma/LzFind.w32.o lzma/Lzma2Dec.w32.o lzma/Lzma2Enc.w32.o lzma/Lzma86Dec.w32.o lzma/Lzma86Enc.w32.o lzma/LzmaDec.w32.o lzma/LzmaEnc.w32.o lzma/LzmaLib.w32.o lzma/Ppmd7.w32.o lzma/Ppmd7Dec.w32.o lzma/Ppmd7Enc.w32.o lzma/Sha256.w32.o lzma/Xz.w32.o lzma/XzCrc64.w32.o lzma/lib7z.w32.a
[ HOST_CC  ]   mlv_dump.host.o
mlv_dump.c:2034:38: error: no member named 'buffer' in 'struct raw_info'
                            raw_info.buffer = frame_buffer;
                            ~~~~~~~~ ^
1 error generated.
make: *** [mlv_dump.host.o] Error 1

I'm having this error too, unable to build mlv_dump on new OSX OS.

Edit: the fix for OSX:

diff -r e12ad3d84e7b modules/mlv_rec/Makefile
--- a/modules/mlv_rec/Makefile   Thu Sep 11 23:50:29 2014 +0200
+++ b/modules/mlv_rec/Makefile   Sun Sep 14 23:59:14 2014 -0700
@@ -6,9 +6,9 @@
# include modules environment
include ../Makefile.modules

-MLV_CFLAGS = -I$(SRC_DIR) -D MLV_USE_LZMA -m32 -Wpadded -mno-ms-bitfields -D _7ZIP_ST -D MLV2DNG
+MLV_CFLAGS = -I$(SRC_DIR) -D MLV_USE_LZMA -m32 -Wpadded -D _7ZIP_ST -D MLV2DNG
MLV_LFLAGS =
-MLV_LIBS = -lm
+MLV_LIBS = -lm -m32
MLV_LIBS_MINGW = -lm

@MonteNero - Had an offline discussion with @Midphase.  It's been pretty well supported that 5d3 owns low light territory (with the possible exception of the new Nikon and other FF dslrs that don't do raw video), so after seeing the footage, I had the same comment.

From what we can tell and if I can remember the convo we had (@Mindphase correct me if I'm wrong), ISO on 5d3 was cranked up high as you would expect to do with a DSLR.  Alexa really has just one fixed iso: 800.  If they had had more time to research, it would have been informative to shoot with the same iso, or a variety.  Also worth noting all the iso/sensor improvements this year.

It would be fun to reshoot the candlelight scene.  Hey, everybody's got access to a candle, right?

+1 ed_mika adapters.  Support this guy, he's awesome!  There are some really exceptional FD lenses out there, especially teles.  Do the research and buy them!
Except the ones I'm bidding on

Old thread I know.

@tronics have you used the Blackmagic hdmi -> usb with a Windows tablet?  If it's compelling it could turn this diehard Android guy to the dark side.

There's a lot of anxiety and occasional conflict around what-to-build.  Recent examples:
http://www.magiclantern.fm/forum/index.php?topic=8210.0
http://www.magiclantern.fm/forum/index.php?topic=7486

I humbly hope a quick post can clarify the process for non-dev users and provide a more constructive for devs.

If ML were a product company, there'd be product managers, project managers, executives who take all of this feedback, prioritize it, choose features, set release dates, etc etc.  The more people who pay to use the product the more developers you get to make it perfect.

Here in ML RAW world it's still wild west.  For example, the product "lets the bones show," meaning the user interface reflects the software model (that's a term by Eric Evans, I like that dude).  This is a Good Thing because it gets everyone speaking the same language.  It might not be intuitive but it's better for the project as a whole.  Everybody wants something a bit different, and some are wondering where the project is headed and why.  Some users see insignificant details being worked on while gaping holes exist elsewhere.

I believe we'll only be here in the wild west once, then it'll be gone like the wind, so let's maximize the fun of the process.  My selfish goal here is developers having fun are developers being productive.  And my theory is that developers write ML code because it's fun.

So, I want to "ask not what ML can do for me but what I can do for ML."  I want to turn this mostly over to developers to ask what kind of contributions you want most from users. 

"Start contributing code" is probably the most obvious answer (and here I feel a bit guilty because I've done embedded C in the past; unfortunately my day job is already 50 hour weeks). But there's probably also some low hanging fruit maintaining documentation like what's changed between releases, to-do instruction videos from a standard place.  If someone PM'd me saying they loved my feature X and wanted to send me a $500 paypal I'd say "duuuh ok" but that's just me.  Hell I'd like to see what my grades from last weekend look in a real cinema theater.  It would be cool to be on set some weekend to see how ML raw could fit on a big budget production.  Maybe you want someone who's not writing code to herd cats - get a handle on what everybody's doing and what everyone's asking for so you can spend less time on the forums with frustrated users and more time writing code. 

OK I couldn't resist the temptation to suggest stuff.  What I really want to ask you developers is what the project needs now.  Actually better yet, what do YOU need right now?

Looks like this is getting fixed!

http://blogs.adobe.com/premierepro/2013/09/adobe-premiere-pro-cc-october-2013-release.html

Resolve 9.1.5 says "support for reel names from FCPXML" has been added.  This fix may be redundant now.

I prefer CinemaDNG -> Grade in Resolve Lite -> Roundtrip to Premiere Pro/CC

On Windows, chmee's raw2cdng.exe http://www.magiclantern.fm/forum/index.php?topic=5618.0 or batchetator http://www.magiclantern.fm/forum/index.php?topic=5645.0 should get the footage.

See http://www.magiclantern.fm/forum/index.php?topic=7030.0 for getting roundtrip working.  The only time-consuming process is generating proxies that you bring into Premiere, but Resolve really rocks for color matching!  Also the proxy part you only really need to do once.  Fortunately it is GPU-accelerated.

In case anyone missed this hidden in The CinemaDNG Discussion some weeks back, I posted a video explaining with the end-to-end workflow including how to fix the round trip issue.

http://www.youtube.com/watch?v=AJzgpIdoUqw

The gist is the "Assist using Reel Names" at 7:30 in the video when exporting FCPXML from Resolve.  I actually burned a whole weekend discovering via trial and error.  The solution finally came to me by ... surprise ... RTFM.  The Resolve Manual, Pg 81 (Conform Options) describes how this works.  There should be at least one more way to accomplish that same process using other Assist Using options, though some development work may be required.

I've gotten some emails requesting clarification on the command-like process.  If your footage is recent and named something like "M04-0843" rather than "M000000" then you need to do nothing to rename the folders and can skip that step.

Further, the process has been tested in both Premiere Pro, PremiereCC, and has been reported to work in FCPX too.  A few users wrote me with problems but had forgotten the step to export the FCP XML out of Resolve and were instead loading proxies manually; so don't forget that.

Is anyone still having round-trip issues after studying the process?  If so please post them here and I'll try to help.

the bmcc-files also had no ReelNo - so, my assumption is, if filename/path/reelName isn't 100% in right order (for resolve) it fails.. i built it in reelname, framerate and timecode and it didnt helped. by now the oneclick in the settings for the reelNo-generation is a no-brainer. for myself i will leave this roundtrip-salvation and make it a sidejob, because its too easy to solve..

Is it true that you can add the reel number into cdng metadata?  Otherwise creating distinct folders would take out half of the pain of this process.

Just throwing out ideas, but you might leave it up to the user to multi select [and append the name]:
[ ] use the raw file sequence (eg M0000000) - though this is not sufficient since we can expect the user to want to use clips from multiple cards and they reset to M0000000 when you power down ML.
[ ] use some string
[ ] use the file creation time of the rawfile
[ ] use the current time

(*) vertical banding
(*) compression
(*) command line
(*) threading for multi-cpu-support

Vertical banding ++ !!!
What do you have in mind for compression?