Messages

Because I very strongly suspect I know what the answer to the question is.

What I'm trying to do here, which seems to have gone flying over everyone's heads, is to emphasise that nobody, as far as we're aware, is actually doing anything wrong.

My opinion of GPL is pretty poor exactly because of this sort of thing. You've got a bit of code you've forced someone to package up in an external executable so as to fulfil some arbitrary set of rules. All GPL is doing in this situation is making software work less well. Very clever, guys, keep it up. It's a stupid set of rules. It doesn't make sense. It doesn't help anyone. But I still wouldn't necessarily encourage anyone to infringe a license and as far as I can tell nobody has. You may not like what's being done, but that's not anyone's problem but yours.

I reiterate. What's he admitted to doing? Where?

P

Sorry - what's he admitted to doing, now?

P

Good grief, is this thread still running?

Let's just examine what happened here. You had a developer stop by to ask if you'd be willing to relicense a trivially small amount of code as a library to allow various applications to maintain compatibility, which helps everyone. You said no, which is of course your right. Probably the wrong thing to do, in my view, but OK.

By the end of the thread people were shouting about lawsuits and GPL violations, even though that's been specifically denied by the developer concerned and there's no reason to believe it's taken place.

This is why people get impatient with the open source movement. It's like dealing with a bunch of schoolchildren.

P

I think further comment here is almost pointless, as there seems to be more interest in open-source flagwaving than there is in creating useful software - but I digress.

No user would ever be confused that one particular software gives different results of some other different software.

Well, they should be! If you don't understand why it's highly desirable - well, essential, if it can possibly be done - for postproduction software to be consistent and to produce identical output from the same input, I can't really help you. Suffice to say - it is desirable, and the modern tendency toward variability in output is a disaster. I can almost see now, from this conversation, why Red won't open their file format! They'd end up in this exact, disastrous situation!

Thomas not releasing his code is "deliberately creating" differences in the output of his program and the output of the open source converters out there.

Well - no - think about it - he's being forced to respin his own solution when one already exists. I've already suggested that a public domain solution should exist, but you folks would have to agree to use it. So... what? What on earth are you on about? This is political rhetoric, not technical discussion, and I've no interest in it.

https://yourlogicalfallacyis.com/black-or-white

But any solution absolutely would be either bit exact, or not. Good grief, it really is beneath me to get involved in this sort of college-level debating society bullshit.

No, you'd simply get more people ripping it off to make money off of it and not contributing back.

So what? The ffmpeg guys already have this happening on a grand scale, and it's hardly destroyed the project. And you don't have anyone else proposing to work on this code, anyway, so you're losing more than you'd gain.

P

The point - to reiterate - is that it's desirable for all the software to give the same results. Any reimplemented solution would be either one of two things:

- Bit exact with the existing solution, which would inevitably provoke accusations of duplicated code, as well as being a huge waste of time, or

- Not bit exact with the existing solution, which creates the problem I'm proposing should be avoided.

Plus, of course, you'd be more likely to get people working on it if they're actually allowed to use the results.

P

You may be satisfied, but unfortunately I'm bound to point out that the users might still be confused by the fact that they don't get the same results with various software. So, they're less likely to be satisfied.

You're absolutely right that inconsistency between software is a problem - and yes, it's a problem. It isn't something we should be deliberately creating. I think that standing on ceremony over the licencing terms of a relatively trivial piece of software is a bit silly, if it risks creating that problem.

P

The fact that the code is open is largely irrelevant if people aren't allowed to use it. Also, there seems to be a fundamental lack of understanding here as to why consistency and compatibility is important, which I find quite mystifying. This isn't really about opensource flag-waving, it's about usable, consistent postproduction software.

Anyway, if that's the situation, I think the best approach would probably be for Thomas to write an anti-banding implementation and release it to the public domain. It's a reasonably trivial piece of code and it might be possible to do better than the current implementation in any case. Of course, the best solution would be for Canon to release their approach, but I can't see that happening.

With a fresh implementation, anyone can use it, we gain consistency, and the entire concern becomes void. I do echo Thomas's concern that any such reimplementation would risk looking very much like the existing one, though.

For that to be valid, anyway, projects like Magic Lantern would need to make the decision to use it. If anyone were interested in doing that it might be worth opening a second thread dedicated to technical discussion of the problem and the sort of approaches that might be used to fix it.

P

First a disclaimer: I'm an acquaintance of Thomas's, but I'm not financially involved in his business. I'm also an admirer of both Magic Lantern and Thomas's past efforts with 5DtoRGB and his other work.

I think the issue here is one of standardisation and compatibility more than it is of who wrote the code.

The banding mitigation code at the core of this issue is intrinsically a best-guess at the ideal correction; it isn't completely perfect and nor can it ever be. That being the case, it is of course perfectly possible for other implementations to be written which would do a similar or better job.

Regardless of the quality of the solution, though, the problem that would create is that we now have two pieces of postproduction software that give different results from the same camera originals. This is not a new issue with any raw-shooting camera, but with a piece of fault-correction code like this, I think it's particularly important that efforts are pooled - which is what GPL is designed to do - but also that a consistent approach is taken, which GPL serves to limit in this case.

My recommendation would be for the anti-banding code to be released to LGPL on the basis that it's very important that everyone is doing the same thing, and that the widest possible group of people can (or are willing to) contribute to the code. Otherwise, MLV is intrinsically an obfuscated file format. That's extremely unhelpful, and might limit the deployability of Magic Lantern in a lot of circumstances.

Phil