Lightroom plugin cr2hdr v3.0 DEV (WIP)

Started by kichetof, March 18, 2014, 05:04:33 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Danne

Here is a little workflow demonstration of using the mlvfs fuse app together with Kitchehofs app converting dual iso movie files. Fusion!



senzazn12

Quote from: Danne on September 22, 2014, 07:55:24 PM
Here is a little workflow demonstration of using the mlvfs fuse app together with Kitchehofs app converting dual iso movie files. Fusion!



Awesome! Thanks Danne!

swinxx

hi,

thank you for that great plugin, although i have a problem because my dual iso video is flickering.
plugin 3.0 alpha 1, same level option applied, used fuse on mac to import into lightroom 5 and then exported the same way as the youtube video in the previous post, imported into after effects and made no changes in acr. (applied visionlog curve)
then exported to 422prores, but video is flickering

thanks, here are some of the not converted and converted files:
https://copy.com/H6fd6AwZxy0G

Danne

I looked at your files and the whitelevel same level did not apply. If you choose "keep log file after conversion" you will be able to see what happens or not with exiftool.
I also noticed some whitelevel stop in the log file with my dng:s but somehow I think exif tool worked anyway. Need some more testing though I believe.

You can drag and drop your dng on one of these droplets to be able to see the exiftool information, whitelevel and so on.
http://owl.phy.queensu.ca/~phil/exiftool/List_Exif_Metadata.zip

Meanwhile you can change white and blacklevel like this and get same level to your dng:s. Just see to it that you get rid of the old exif temp files in the folder.

Exiftool -r *.DNG "-WhiteLevel<BlackLevel" -overwrite_original
Exiftool -r *.DNG "-WhiteLevel+=50000" -overwrite_original

1 - open terminal and write Exiftool -r *.DNG "-WhiteLevel<BlackLevel" -overwrite_original then hit space once.
2 - drag your folders or a single folder containing more folders on top of the terminal command (command -r will search all folders). Hit enter. Command line will run through the DNG;s. Wait until all files are finished.
3 - run the same again but now with the other command line Exiftool -r *.DNG "-WhiteLevel+=50000" -overwrite_original hit space once.
4 - drag your same folders or a single folder containing more folders on top of the terminal command (commando -r will search all folders). Hit enter.

Terminal might be giving some warnings about not finding dng,s but the command seems to run anyway.

Danne

Yes, I can confirm something fishy going on with exiftool. According to txt file whitelevel can,t update dng tag data through mlv files using the fuse workflow.

Conversion works fine, exiftool has some problems and it also seems it goes into a loop.

[img=http://s29.postimg.org/3rja8n0wj/Screen_Shot_2014_09_22_at_21_33_31.png]

[img=http://s29.postimg.org/kum245hlf/Screen_Shot_2014_09_22_at_21_34_35.png]

[img=http://s29.postimg.org/vg5xg5nwz/Screen_Shot_2014_09_22_at_21_35_53.png]

swinxx

hi,

i have tried with mlvmystic_05,
no flickering.

you can find images in the shared directory from my previous post..
greets. 

Danne

Mlvmystic gives flickery files. My 2,5k video shows this. Maybe not on your specific file.
Due to gpl issues and the total lack of maintenace on the app Mlvmystic is not supported by me anymore. The latest 20bit cr2hdr binary is the better one anyway.

swinxx

so one interesting finding:

i downloaded the newest exiftool from here:
http://www.sno.phy.queensu.ca/~phil/exiftool/

i showed the content of the lr plugin and changed exiftool and the lib files.

then i converted the same file agains and voila, everthing looks great now, although i get an error that a file could not be imported, but i must check again, cause the converted files are here.. i have rendered the sequence and no more flickering :)

Danne

Are you on mac or windows? Soounds great. How do you extract exiftool binary and lib folder?

swinxx

hi,
i am on a mac,
just download it,
show the content of the plugin file of the kichetof plugin, find the exiftool and libs and replace them with the downloaded files from the link provided in the previous post.

greets. for the next 5 minutes i will be in the chat if you have problems, my nick is swinxx :)

Danne

There is a chat :)? Tried writing in the livechat but no success.
Got the files replaced as you suggested, found the through your link but still the same hickup. Did you see the textfile? WHat does it say?

kichetof

hum, I'm really surprised that change exiftool into cr2hdr.lrplugin changes anything.
cr2hdr on Mac use exiftool from $PATH and not from plugin path. I tried to pull request but I don't have the knowledges to do that properly.

Try to update exiftool from ~phil with the newest version (9.71) and try again and let me know !
I think that the problem come from exiftool, the same with your external hard drive, maybe a permission error. Could you run into a terminal ls -l on your MLVFuse folder to compare permissions and groups.

I need to try with MLVFuse but not enough time to make all try :(

@Danne, which Mac do you have ‽ soooooo fast!!!
@swinxx do you have updated MLProcess.lua from source on Beta 1 ?

swinxx

@kichetof:

thank you for your reply,
no i used the download link from the first post,
then i changed the exiftool to 9.71

you can have a look at all files in the shared folder,

thank you

swinxx

sadly, i have not the skills to compile for myself :)

kichetof


Danne

Hi Kitchehof! I ran the ls -l  command on the fuse folder. Goes like this:
[img=http://s24.postimg.org/bo0cxawch/image.jpg]

Tried updating and also running the exact same plugin version as swinxx but I always get the couldn,t update the whitelevel error.

My mac is faster than the wind ;). Na, I cut out the wait in premiere pro, makes the computer look like a beast mac pro :)

kichetof

Thanks Danne! Could you run the same command where dualiso files are present with exiftool temp file?

Oh shit! It looks so real! I'm waiting the new MacBook Pro generation to changes my old but lovely
MacBook Pro 2008 :D

Danne

New macbook pros is what we need :)

So here are  three different folders:

Original folder with mlv files
[img=http://s9.postimg.org/jr9xk30jv/image.png]

MLD folder created in the mlv orginal folder. Also containing converted dng files
[img=http://s9.postimg.org/o1olfo5mz/image.png]

Inside the fuse app there is also dng:s being created in the folder
[img=http://s9.postimg.org/8u8lvbdsb/image.png]


Might be hitting the bed now. More investigating tomorrow. Thanks again.

kichetof

Hi Danne! Thanks for your printscreens! After a little but good night I see something :)

On the second picture, inside MLD folder, your rights are rwrr (644) but... I've a doubt with cr2hdr or exiftool with permission to run into user or by system/service.
Maybe the permissions could be rwrwr (664) or rwrwrw (666). I think this is a issue with MLVFS service that allow write permission only for user but not for groups or others.

I'll read MLVFS source and fuse permission to help to solve this issue!

After reflection, cr2hdr is launched by Lightroom with user confirmation, so I think it's the command line to exiftool inside plugin that run by other than user and have no permission for write into the folder.

Danne

Yes, I think you, re right about permission handling. Hope it could work somehow :)

kichetof

MLVFS Source: main.c

ALLOW_WRITEABLE_DNGS on line 292 aren't set to true but, a comment on lines 41-43 explain a problem with write permission. Maybe try to set to TRUE and compile MLVFS! I'm not at home with no Mac under the hands! Not easy on iPhone or iPad 8)

Danne

hehe, well, I,m off to work and my compiling skills a bit weak  :P, but there is no hurry at all for me :)

dmilligan

#define ALLOW_WRITEABLE_DNGS
at the top of the file is enough to make it "true" because we don't do:
#if ALLOW_WRITEABLE_DNGS
instead, we do:
#ifdef ALLOW_WRITEABLE_DNGS

Though, this is not really a permissions issue.  It's impossible to actually allow writing to the "virtual" DNGs, they are generated on the fly from the MLV file, but we mark them as writeable so that AE doesn't throw an error. (I'm sort of against this, which is why there is a macro that disables it). It seems that AE doesn't actually try to write to the DNGs and falls back to using an XMP, it just wants them to not be readonly.

Danne is sort of using MLVFS in a way I never intended, that is to be writing DNGs into the MLVFS. I was pretty much intending that the only DNGs would be the virtual ones created by the MLVFS, so it's interesting to me that his method works at all.

The correct thing to do would be to have cr2hdr read from the MLVFS DNGs and then write the converted DNG somewhere else outside of the MLVFS mount directory.

I will investigate this type of workflow and see what I can come up with.

senzazn12


Quote from: dmilligan on September 23, 2014, 01:23:10 PM
#define ALLOW_WRITEABLE_DNGS
at the top of the file is enough to make it "true" because we don't do:
#if ALLOW_WRITEABLE_DNGS
instead, we do:
#ifdef ALLOW_WRITEABLE_DNGS

Though, this is not really a permissions issue.  It's impossible to actually allow writing to the "virtual" DNGs, they are generated on the fly from the MLV file, but we mark them as writeable so that AE doesn't throw an error. (I'm sort of against this, which is why there is a macro that disables it). It seems that AE doesn't actually try to write to the DNGs and falls back to using an XMP, it just wants them to not be readonly.

Danne is sort of using MLVFS in a way I never intended, that is to be writing DNGs into the MLVFS. I was pretty much intending that the only DNGs would be the virtual ones created by the MLVFS, so it's interesting to me that his method works at all.

The correct thing to do would be to have cr2hdr read from the MLVFS DNGs and then write the converted DNG somewhere else outside of the MLVFS mount directory.

I will investigate this type of workflow and see what I can come up with.

I see. Aren't we basically just making physical copies of the virtual DNG's using Danne's method when we export through LR? This would reduce storage space but is great for people who like to use LR for grading their shots.

There is a save metadata function in LR. Wondering if we could use that to save the metadata of the virtual DNG's so all the settings and editing we do in LR will be the same when opening the same DNG's in After Effects.

I have used this workflow before in LR with physical DNG's and all the settings I would apply there would be the same when opening in After Effects for export. This method saves time and space instead of re-exporting the edited DNG's in LR to use in After Effects.

The reason I grade in Lightroom is because I can go through the many DNG's in an MLV clip to see which scene I want to base my color grading on. In After Effects, when you open ACR, they only give you the first DNG to do your color grading on which is not practical if it was a panning shot and you wanted to do your color grading on a scene midway through the clip. I heard there is a workaround for this by using Adobe Bridge but couldn't get it to work.

dmilligan

Everything works as it should if you would like to grade through Lr and then import into AE. Lr will create XMP sidecar files (it doesn't try to write to the DNGs unless you force it to), that contain all the ACR settings you selected. When you open the sequence in AE it sees the sidecars and these settings are applied.

MLVFS allows Lr to create XMP sidecars in the virtual directory structure by passing them through and storing the actual data for them in the real filesystem (in the xxx.MLD directories). This is how I designed it and expected it to work. The data for the virtual filesystem comes from two places: real files that appear in the .MLD directory are "passthrough", and "virtual" .dng (and .wav) files that are created on the fly by MLVFS.

What throws a monkey wrench in is trying to convert dual-ISO via the Lr plugin, within the virtual file system. I did not design it to allow you to write real/converted .dng files into the virtual filesystem. The only DNGs in the virtual filesystem should be the virtual .dngs, not ones that are "real" and passed through to the xxx.MLD directory. It's actually sort of "bug" that Danne's method works at all. That is what's causing the issues with exiftool. There is a better solution, I just need to figure out what that is, and what changes need to be made to MLVFS.



OT: please don't put in full quotes of posts, the text is right above, we can read it there, it makes these threads unnecessarily long; making specific quotes to respond to specific questions is fine