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 - martinhering

#27
Quoteeverything else looks like it was totally rewritten from scratch.

This is what I told all along. For the vertical stripes correction however, I used the code of mlvdump as a reference. As @a1ex told me this is derivative work nonetheless and thus falls under the terms of the GPL.

To be honest it is now much easier for me to have all the MLV code under GPL. This way I don't need to care anymore about the licensing issues. I am fine with that. The only question that remains is, if it is possible now to integrate the mlvprocess binary into a commercial project and communicate over inter-process communication mechanisms. I could not find anything about that. All I can find is, that you can't dynamically or statically link a library. But XPC should be the same as starting a command line tool and sending messages over the shell conceptionally, which should be fine. Not?
#28
QuoteI updated to your new build 150, but it does not open a window. There is only the footage menu bar and the icon in the dock.

Sorry about the crash on 10.11 again. I fixed that now. Please download the most recent build 151.

QuoteSame issue here. The release notes mention "Updated expiry date" is the app going to stop working at some point?

This is only a measure to invalidate old alpha/beta builds. I don't want to have a lot of old and buggy builds in the wild. With every update comes a postponed expire date. Don't worry. Once the app is 1.0, the expire date will be removed entirely.

And sorry for the short update release notes. I am currently very pressed on time and can't invest a lot of effort into this project. With the latest build, I actually improved white balance estimation by a lot. Thanks to @Andi600 for his help.
#29
Yep, thank you for the correction.

@g3gg0
Any comments?
#30
QuoteJust curious if you're still planning to expire the current version on the 15th. I've become quite fond of using it to see the take before exporting to CNG.

I just bumped the version number and increased the expire date by 1 month. Sorry, that I did not have the time during the recent 2 weeks to improve the app further. I was very busy with a client project. The money has to come from somewhere, right?

QuoteCall it log and transfer and put it on the App Store haha!!

Actually, the app can't be put onto the app store, because it can not be sandboxed at this time. This is due to the fact that mlv files can be split up into chunks. In sandbox mode however, the app can not read all the chunks automatically when you only open the .mlv file. I would need to force the user to select all the chunk files, which is not a good user experience. Drag & drop wouldn't work either.

QuoteI also get a pinkish picture for every clip on all my Macs as @togg got on page 6 of this thread. Is there a solution yet?

Unfortunately I don't know what causes this magenta shift. I can only image that it is yet another bug of Apple's raw engine. I am thinking in replacing it altogether anyway. The app wouldn't be as fast anymore, but what is performance if the quality sucks, right? Would it be possible for you to send me a short example clip, maybe only a silent picture?
#31
In the open-source MLV processing tool, I am developing, I just encapsulated all the mlv interfacing API into an XPC service. Any commercial application could now integrate this XPC service in binary form and communicate with it via inter-process-communication. It would be great if somebody could review the code and tell me if that would be an acceptable way to go integrating MLV into a commercial app.

https://github.com/martinhering/MacLantern/tree/develop

The XPC process code is here:
https://github.com/martinhering/MacLantern/tree/develop/mlvprocess

There in 1 header file that needs to be integrated into the commercial app, that's why I gave it the LGPL license.

And here is how the commercial app would communicate with the xpc service:
https://github.com/martinhering/MacLantern/blob/develop/MacLantern/MLVJob.m

One caveat, I think that also needs to be true is, that the commercial application can not solely depend on that xpc service. The integration of that service needs to be optional. Otherwise I think the whole commercial app could be seen as derived work again.

I hope you can see, that this issue is very important to me and that I am doing what I can to be compliant. If this method is not working for you, I think I need to give up. I can't think of any other options.
#32
@lostfeliz

Sorry, I didn't have the time yet to check this out. Still on it. Unfortunately right now, I have other priorities and the scope and timeline of my app has been extended by a lot.
#33
OK, here we go. I created a project on Github for the mlv conversion tool and published the first batch of code that's interfacing with MLV. Check it out.

https://github.com/martinhering/MacLantern/tree/master/MLV
#34
A idea I had was an option in mlv_dump to recompress existing mlv files. Might be useful for some, who like to archive MLV instead of CinemaDNG. It would also be useful to have an option for compressing the raw image when converting to CinemaDNG.
#35
QuoteAs much as I want to understand this (I do, literally) but this time bomb hogshit is pretty much a 'slap in the face' to those that have helped you get up to this point, including myself.

I am happy to send out an update that postpones the expire date, if nobody gives me problems about the GPL issues.

QuoteAnyway, here's another bug w Version 0.3 (141) and not sure if this matters but noticed if I try to use a single MLV file larger than 40-50GB or so from the import window which then freezes and hangs the app. Thus forcing me to quit.

I found this out myself. There is some UI missing that shows an import progress. The app needs to scan the whole file and make an index. This can take awhile depending on the speed of your hard drive usually. I am planning to improve this with the 0.4 alpha.
#36
Quotebtw this was *not* reverse engineered from the firmware.
this was just done by looking at the images and trying to compensate errors in them.

Ok, but if you actually do this all by yourself again, nobody would believe you anyway and accuse you of violating GPL (not saying I did this work by myself, I actually looked at the code, so I am guilty). So then you would be back at square one. It's really not worth it to go through all this trouble.

Quotei don't know apple compressor, sorry. as long it doesnt violate licenses, i am fine with it

If it's GPLed, it's fine right?
#37
Quotewhile i understand your decision, i still wonder what the time bomb is trying to solve.
did someone issue an ultimatum?

No, no one did. I usually build time bombs into my alpha and beta versions, because I don't want everybody to use buggy software forever. The software expires now, because I don't want to put out an update while the GPL situation isn't clear. I did not know about the "derivative work" issue before and I also thought that I can make it work, but obviously I can't.

Quotecontribute back to the GPL world with your access libraries.

I will.

Quoteif you read my post at http://www.magiclantern.fm/forum/index.php?topic=7122.msg59525#msg59525
you will find "mlv file structures in C: here (LGPL)" which is a LGPLed mlv.h
maybe it helps with that issues.

That's great. But raw_info structure is missing. Also mlv_rawc_hdr_t is also missing. This header needs an update. But that's beside the point. You can't actually make an MLV tool and not make it GPL, because anything you do would be derivative work, because you can't providing a clean room implementation. If you want to interface with MLV, you have to do a lot of stuff, to make the RAW footage usable, like fixing dead pixels, fixing focus pixels, fixing vertical banding, handling Dual-ISO and white balance correctly, etc. All this is impossible without looking at the firmware code. The mlv.h header is not enough information.

Quoteunfortunately your tool will only help commercial users as hobbyists probably won't pay for this tool.
thats why we prefer open sourced end user tools.

Sorry, my idea is not yet fully backed. Still thinking about this. I don't know if you know Apple Compressor. It's a batch processing tool. That's what I have in mind for the open-source MLV tool really with an additional XPC component to communicate with other processes headlessly. So, it is an end user tool that does all the fixing work, it's just not developing, managing and archiving all the footage.
#38
@Lars Steenhoff
QuoteWill the interfacing between the mlv part and the gui be seemless?

I answered your question over at the app specific thread.
#39
If you read this thread here, you already know that I will be changing the app significantly. The app will continue to be a management and development tool for Mac, but it won't be solely based on MLV. There are other cameras, I like to support in the future, like Black Magic Ursa, Sony FS Series, Canon C Series, DJI X5R, ARRI Alexa, etc that shoot RAW. So I will mainly focus on Cinema DNG. MLV will be supported through an external tool, that will be open-source. I will try to interface this tool using inter-process communication, to make the integration as tight as possible, but you are free to use other conversion tools as well.

The current build expires on May 15 and unfortunately I won't be able to release a new version until I restructured the app. I hope you all understand. Thank you for your understanding and support.

Martin
#40
All valid points, thank you, besides this one which does not make any sense to me:

QuoteWill this thread lead to the end of ML?

Regardless. I decided to split the application up.

  • My user-interface application will not be based on MLV anymore, but on DNG. This will open the app up to all kinds of cameras and not be limited to some Canon models and gets rid of the GPL questions.
  • I will be developing an open-source tool (not necessarily command line) that can be interfaced from other applications, that will do the job of converting MLV to Cinema DNG. You are free to using mlvdump, if you like.
Keeping it a commercial app is also better for supporting other commercial technologies like licensing codecs and such.

Quote[...]command line tools while more difficult for some people are supported on all platforms

The conversion tool won't be platform independent, because I am a Mac/iOS programmer and I can do a better and more efficient job when using Apple APIs (when dealing with images e.g.).

QuoteThink also about the benefits of releasing the app for free and accepting donations.

I worked my whole life on commercial apps. That's what I know. I know nothing about donations. I am not the right guy for this model.

I hope everyone, well almost everyone can be happy with this solution.
#42
I like to publish a commercial application that deals with MLV footage on MacOS. So far it's free for download and I have really positive feedback and users like it.

But recently I came to the conclusion that it is just not possible for me to publish the app as it is right now and not violate the GPL as it is regarded by members of this project. I wrote all the code myself and don't use any GPLed source code. However after talking to @a1ex I also think it's still a derivative work and no matter what I do, it will always be derivative work, because it is simply impossible to provide a clean room implementation. You have to look at the Magic Lantern source code to even understand the MLV file format.

So, I don't want to violate the GPL and I don't want to be a dick to everybody that is developing for this wonderful project. I am writing this post here, because I like your input. I am in a dilemma and I like to know what behaviour is acceptable.

I don't want to publish the source code of the whole app, because 1) there is a big issue with asian and eastern Europe based developers who just take your source code from GitHub and put it into the App Store for money and 2) I like to support my family and bring in a little money. As far as I can see, I have 2 options:

1) Stop developing my app and remove all downloads from the internet. The current version is time bombed and expires May 15.

2) Find a solution to publish some of the source code, that is actual derivative work as open source under GPL and keep the rest commercial. I was thinking about a command line tool, that can be interfaced from any app.

What would you guys prefer? And what is the technical acceptable way to go with option 2?
#43
Yeah, that's a bug. Thank you. Will fix that. I'll also add QuickLook for the Finder. Those icons doesn't look very good.
#44
It should do that already.
#45
@togg
When you have specific bugs, please use the "Support" form in the "Help" menu. Here in the forum, it just scrolls by and I have difficulties of tracking the issues. Also with something like hot pixel correction not working, it would be great if you could upload the MLV somewhere for me to download and check out. That would be awesome.

@Lars Steenhoff
Converting the DNG and developing them in Resolve or AfterEffects should be fine (apart from the WB issue, that's going to be fixed shortly), but using the ProRes output as final footage has color and dynamic range problems for now. I think, I won't be able to solve that in the short term, since this is a problem with Apple's RAW engine itself. I would need to develop my own RAW engine and this is out of scope for now. I will continue developing the app more as a preview and organisational tool. Professionals should always export CinemaDNG and not ProRes for the moment.
#46
Quotebut as someone who discounted ProRes a little while back in favour of the GPU accelerated preset resolution Cineform codec, do you think there is any chance export in such codec might be possible to add down the road?

Sure why not.

Quote...and wondering if there might be any chance you could port the code back to Yosemite like I saw someone else enquire about.

Not at the moment, because Yosemite lacks some specific RAW APIs, my app currently needs.

QuoteThe exported dngs have a different colour and exposure level than the one out of mlv_dump/mlrawviewer, is this by design?

DNGs dont have color or exposure levels. These parameters are used during processing of a raw image. But with the help of @Andy600 I found some color issues with the app, notably false Camera Matrixes in the DNG metadata that effects white balancing. This will be fixed with the next update.

Also @Andy600 made me look deeper into the innards of Apple's RAW engine, and I did not really like what I saw. There is a deep, deep problem with how Apple handles color and converting into multiple color spaces. I am currently investigating this issue.
#47
New Build 0.3 (141)

Changes in this version:

  • Added showing Cold and Hot Pixels
  • Added Metadata tab in properties
  • Added Broom tab in Properties for fixing defects functions
  • Added decoding Lossless JPEG
  • Removed old "Discolored Highlights" filter
  • Added new "Defringe Highlights" filter to reduce Magenta around clipped highlights
  • Added "Fix Dead Pixels" raw filter
  • Improved window layout on small displays
  • Improved user interface icons
  • Added "Fix Vertical Banding" raw filter

https://rink.hockeyapp.net/apps/3ed6ecf60e684239a6aba3d407cf3935/app_versions/77
#48
@MitchLally

QuoteWhen you decode the .MLV, do you assign a black and white level to the frames? I've noticed that bright highlights are unrecoverable with the highlight and exposure slider. When I set the white level to 16383 (5D 3) in MLV_DUMP I get the full dynamic range in the highlights (no clipping) on the same shot in resolve or ACR.

I am not correcting white or black level so far. Just taking whatever the MLV file says.
Could you please send me two DNG files that show the effect you are talking about? One with the corrected white level and one without the correction? Thank you.
#49
@ giarcpnw

Yeah, it's definitely worse with your camera than with mine. Would be awesome, if you could put the mlv file for me somewhere to download.
#50
@giarcpnw
QuoteNow, with the advancement of the 4k raw and 14bit lossless the issue of Vertical Lines has resurfaced. Looks like no one has addressed I yet in the decoder softwares. I tried mlv-dump, cr2hdr and your latest build. How did you address fixing vertical lines in your older builds? And can you do it for the new 4k raw stuff? Or does the Footage app rely on another engine?

About the vertical stripes problem, I don't get that in most of my shots. I have yet to find an example where the problem is really visible. Can you provide such a file?

[UPDATE]
OK, when I heavily process the image, I can see those stripes. I will add a correction for that. Can take a while though.