Hello everyone,
Can anyone report if its working probably?
Iam shooting with AutoETTR and Post Deflicker. Deflicker generates a sidecar file (.xmp) which normally Adobe Bridge will recognize. But nothing happens (the file is there and when i load it nothing happens) and i need to correct my shoots manually ....
The .uraw file is working with Gimp, but i want to use xmp´s
Iam using latest nightly build + Tragic Lantern 2.0 + 600d
baq
Quote from: Baquster on May 26, 2013, 07:25:47 PM
Hello everyone,
Can anyone report if its working probably?
Iam shooting with AutoETTR and Post Deflicker. Deflicker generates a sidecar file (.xmp) which normally Adobe Bridge will recognize. But nothing happens (the file is there and when i load it nothing happens) and i need to correct my shoots manually ....
The .uraw file is working with Gimp, but i want to use xmp´s
Yes it works, I tested today. :D
But... the xmp files are not correct yet :(
You need to open each one of them and delete the first line such as : <?xpacket begin='' id='W5M0MpCehiHzreSzNTczkc9d'?>
I used ACR and it adjusted the exposure correctly for Flicker Free Timelapse.
I am sure this will be corrected in the future.
Make sure you visit:
Flicker Free ETTR Timelapse: - -Beginners Guide & Basic Post Processing --
http://www.magiclantern.fm/forum/index.php?topic=5705.0
and
ETTR (Exposure to the Right): - -History & Beginners Guide --
http://www.magiclantern.fm/forum/index.php?topic=5693.0
Thanks for trying !
Yeah, i read the topics but i didnt wanted to ask there :)
Today i tried it again with the new built, but i couldnt make it with your trick of deleting a line ;)
They changed something with the XMP´s i could read in the commits.
See you!
This has now been fixed. Currently, if you have adobeRGB set as your default color space in the Canon menus, the XMP files are not named to reflect the different naming Canon uses.
The solution is to set sRGB as your default color space, or rename the XMP files replacing the 'D' with an '_', or wait until a dev investigates the issue.
I am still having problems with ACR reading correctly the XMP files. In most situations ACR 6.7 and & 7.1 are ignoring the exposure compensation included in the XMP file. Does anybody have an XMP file generated by LTRTimelapse? It might be helpful to see how they structured it.
New solution to XMP files with today's build
Found out that the XMP file need to be converted to UTF-8 format.
1. Download this little converter: http://www.softpedia.com/get/Science-CAD/UTF-8-converter.shtml
2. Process all of you xmp files to change their format
3. Open the images in ACR and the exposure will be automatically adjusted based on the information of the XMP file
So for now.. it appears the problem is solved!
I also tested with Lighroom 4.2, ACR 7.1, and ACR 6.2 and all work!!!
Is there a solution for mac ? :)
Can you send me a converted file? UTF-8 is a superset of ASCII, so I don't see why it would make a difference... there are no special characters inside.
Will do.. There are no special characters added or deleted when going from ANSI to UTF-8, it appears there is something in Adobe products that is particular about the file format for XMP files.
Need help with this. I don't use Adobe software, so I have no idea how it should work.
https://bitbucket.org/hudson/magic-lantern/commits/b0e30d11ac33
https://bitbucket.org/hudson/magic-lantern/commits/9225b8ee429c
Using ACR Beta 8, can't downgrade it seems.
I'm finding that some XMP's are being picked up by ACR, and other aren't. To me, the XMP's look exactly the same (except exposure of course). I've noticed this in all the builds where XMP has worked.
Here is a zip (https://dl.dropboxusercontent.com/u/34113196/Camera%20stuff/ML/XMP.zip) of some XMP's if you want to have a look at them.
2623, 2626, 2627, 2628 are the ones that work.
Quote from: Audionut on June 05, 2013, 01:43:29 AM
I'm finding that some XMP's are being picked up by ACR, and other aren't. To me, the XMP's look exactly the same (except exposure of course). I've noticed this in all the builds where XMP has worked.
Now Download this little converter: http://www.softpedia.com/get/Science-CAD/UTF-8-converter.shtml
And process the xmp files and try them again with ACR
That does indeed fix it.
A zip (https://dl.dropboxusercontent.com/u/34113196/Camera%20stuff/ML/XMP_fixed.zip) with original XMP and fixed XMP with the prog above.
Quote from: Audionut on June 05, 2013, 03:20:37 AM
That does indeed fix it.
A zip (https://dl.dropboxusercontent.com/u/34113196/Camera%20stuff/ML/XMP_fixed.zip) with original XMP and fixed XMP with the prog above.
Great, thanks! Now we are having a really hard time figuring out what is the converter doing? If you look at text inside the file there are no changes. My understanding of ANSI and UTF-8 formats is null.
Even at binary level, the two files are identical.
Maybe it's the timestamp?
ACR reports CR2 files with date created and date modified. Always 1 second apart. On a quick test of 9 files, all the working XMP files have a date created time = date modified time in ACR, all the 'borked' XMP's have a date created time = date created time in ACR.
Alex, what software do you use?
I use ufraw; no idea how to use those XMPs.
Can you try to change the timestamps manually? Some hints: http://stackoverflow.com/questions/51435/windows-version-of-the-unix-touch-command
That fixed it.
edit: It's not always a 1 second time difference between date created and date modified CR2 timestamps. I just noticed 1 a little longer.
Okay, so in ML I should delay the file creation by one second?
I think 1 second should be safe. It's already got a small delay anyway obviously.
But what problems is this going to cause with photos taken in quick succession? Can you delay the creation as you see fit without causing problems for anything else? In which case I would say to delay by 2 seconds to be on the safe side.
Is it possible to fake the date creation time instead?
Also it may convenient to investigate a more complete XMP file since ACR assumes it is 2010 profile and does not allow all the slider adjustments. At least in my case some of the sliders are off to one side.
As as test I just opened the files in notes and close them, with the new date stamp all are recognized by ACR
Well, send me some sample files from 2012 or whatever is recent.
It's not working anyway for burst pics.
https://dl.dropboxusercontent.com/u/34113196/ML/D46A2620.XMP
Updated the template. Does it still need the timestamp hack?
That's broken it completely.
Changing the exposure tag back to previous gets them to be recognized again.
-" <crs:Exposure>%s%d.%05d</crs:Exposure>\n"
Doesn't fix the timestamp problem though.
Can you figure out a template that's recognized as a recent profile? Minimalist if possible, without that ton of parameters.
Quote from: RenatoPhoto on June 05, 2013, 04:09:53 PM
Also it may convenient to investigate a more complete XMP file since ACR assumes it is 2010 profile and does not allow all the slider adjustments. At least in my case some of the sliders are off to one side.
Instead of being central with highlight/shadow adjustments possible +-, 2010 makes them on the left side (as you see). You can still make adjustments with them though, it's just that afaik, you can only reduce the highlights or boost the shadows etc without being able to boost
or raise either one like with the 2012 process.
edit: Will do a1ex. Bed time here, I'll have a look at it tomorrow.
Couldn't help myself.
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Magic Lantern">
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about=""
xmlns:crs="http://ns.adobe.com/camera-raw-settings/1.0/"
crs:ProcessVersion="6.7"
crs:Exposure2012="-2.69854">
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>
Night!
I tried: LRTIMELAPSE
put abc.dng and xyz.cr2 in
Folder 2010 --> LRTimelapse (in LR3 Mode) --> Inititialize --> Save XMP
Folder 2012 --> LRTimelapse (in LR4 Mode) --> Inititialize --> Save XMP
Header 2010: (LR3)
<?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?>
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.1.0-jc003">
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about=""
xmlns:crs="http://ns.adobe.com/camera-raw-settings/1.0/">
<crs:Version>6.4</crs:Version>
<crs:ProcessVersion>5.7</crs:ProcessVersion>
<crs:WhiteBalance>Custom</crs:WhiteBalance>
<crs:Temperature>5850</crs:Temperature>
<crs:Tint>8</crs:Tint>
<crs:Exposure>0.0</crs:Exposure>
<crs:Shadows>5</crs:Shadows>
<crs:Brightness>50</crs:Brightness>
<crs:Contrast>25</crs:Contrast>
<crs:Saturation>0</crs:Saturation>
<crs:Sharpness>25</crs:Sharpness>
<crs:LuminanceSmoothing>0</crs:LuminanceSmoothing>
<crs:LuminanceNoiseReductionDetail>50</crs:LuminanceNoiseReductionDetail>
<crs:LuminanceNoiseReductionContrast>0</crs:LuminanceNoiseReductionContrast>
<crs:ColorNoiseReduction>25</crs:ColorNoiseReduction>
<crs:ColorNoiseReductionDetail>50</crs:ColorNoiseReductionDetail>
<crs:ChromaticAberrationR>0</crs:ChromaticAberrationR>
<crs:ChromaticAberrationB>0</crs:ChromaticAberrationB>
<crs:VignetteAmount>0</crs:VignetteAmount>
<crs:ShadowTint>0</crs:ShadowTint>
<crs:RedHue>0</crs:RedHue>
<crs:RedSaturation>0</crs:RedSaturation>
<crs:GreenHue>0</crs:GreenHue>
<crs:GreenSaturation>0</crs:GreenSaturation>
<crs:BlueHue>0</crs:BlueHue>
<crs:BlueSaturation>0</crs:BlueSaturation>
<crs:FillLight>0</crs:FillLight>
<crs:Vibrance>0</crs:Vibrance>
<crs:HighlightRecovery>0</crs:HighlightRecovery>
<crs:Clarity>0</crs:Clarity>
<crs:Defringe>0</crs:Defringe>
<crs:ToneCurveName>Linear</crs:ToneCurveName>
<crs:ToneCurve>
<rdf:Seq>
<rdf:li>0, 0</rdf:li>
<rdf:li>255, 255</rdf:li>
</rdf:Seq>
</crs:ToneCurve>
<crs:CameraProfile>Adobe Standard</crs:CameraProfile>
<crs:LensProfileSetup>LensDefaults</crs:LensProfileSetup>
<crs:GradientBasedCorrections>
<rdf:Seq>
<rdf:li rdf:parseType="Resource">
<crs:What>Correction</crs:What>
<crs:CorrectionAmount>1.0</crs:CorrectionAmount>
<crs:CorrectionActive>true</crs:CorrectionActive>
<crs:LocalExposure>0.0</crs:LocalExposure>
<crs:LocalSaturation>0.0</crs:LocalSaturation>
<crs:LocalContrast>0.0</crs:LocalContrast>
<crs:LocalClarity>0.0</crs:LocalClarity>
<crs:LocalSharpness>0.0</crs:LocalSharpness>
<crs:LocalBrightness>0.0</crs:LocalBrightness>
<crs:LocalToningHue>230.0</crs:LocalToningHue>
<crs:LocalToningSaturation>0.0</crs:LocalToningSaturation>
<crs:CorrectionMasks>
<rdf:Seq>
<rdf:li rdf:parseType="Resource">
<crs:What>Mask/Gradient</crs:What>
<crs:MaskValue>1.0</crs:MaskValue>
<crs:ZeroX>0.5</crs:ZeroX>
<crs:ZeroY>0.6</crs:ZeroY>
<crs:FullX>0.5</crs:FullX>
<crs:FullY>0.2</crs:FullY>
</rdf:li>
</rdf:Seq>
</crs:CorrectionMasks>
</rdf:li>
<rdf:li rdf:parseType="Resource">
<crs:What>Correction</crs:What>
<crs:CorrectionAmount>1.0</crs:CorrectionAmount>
<crs:CorrectionActive>true</crs:CorrectionActive>
<crs:LocalExposure>0.0</crs:LocalExposure>
<crs:LocalSaturation>0.0</crs:LocalSaturation>
<crs:LocalContrast>0.0</crs:LocalContrast>
<crs:LocalClarity>0.0</crs:LocalClarity>
<crs:LocalSharpness>0.0</crs:LocalSharpness>
<crs:LocalBrightness>0.0</crs:LocalBrightness>
<crs:LocalToningHue>50.0</crs:LocalToningHue>
<crs:LocalToningSaturation>0.0</crs:LocalToningSaturation>
<crs:CorrectionMasks>
<rdf:Seq>
<rdf:li rdf:parseType="Resource">
<crs:What>Mask/Gradient</crs:What>
<crs:MaskValue>1.0</crs:MaskValue>
<crs:ZeroX>0.5</crs:ZeroX>
<crs:ZeroY>0.4</crs:ZeroY>
<crs:FullX>0.5</crs:FullX>
<crs:FullY>0.8</crs:FullY>
</rdf:li>
</rdf:Seq>
</crs:CorrectionMasks>
</rdf:li>
</rdf:Seq>
</crs:GradientBasedCorrections>
<crs:HasSettings>True</crs:HasSettings>
<crs:CropTop>0.0</crs:CropTop>
<crs:CropLeft>0.0</crs:CropLeft>
<crs:CropBottom>1.0</crs:CropBottom>
<crs:CropRight>1.0</crs:CropRight>
<crs:CropAngle>0.0</crs:CropAngle>
<crs:CropConstrainToWarp>0</crs:CropConstrainToWarp>
<crs:HasCrop>True</crs:HasCrop>
<crs:AlreadyApplied>False</crs:AlreadyApplied>
<crs:RawFileName>IMG_2483.CR2</crs:RawFileName>
</rdf:Description>
<rdf:Description rdf:about=""
xmlns:xmp="http://ns.adobe.com/xap/1.0/">
<xmp:Rating>0</xmp:Rating>
</rdf:Description>
<rdf:Description rdf:about=""
xmlns:lrt="http://lrtimelapse.com/">
<lrt:ReferenceBoxX1>0.0</lrt:ReferenceBoxX1>
<lrt:ReferenceBoxX2>1.0</lrt:ReferenceBoxX2>
<lrt:ReferenceBoxY1>0.0</lrt:ReferenceBoxY1>
<lrt:ReferenceBoxY2>1.0</lrt:ReferenceBoxY2>
<lrt:ReferenceKeyFrame>false</lrt:ReferenceKeyFrame>
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>
<?xpacket end="w"?>
Header 2012: (LR4 with new Sliders)
<?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?>
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.1.0-jc003">
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about=""
xmlns:crs="http://ns.adobe.com/camera-raw-settings/1.0/">
<crs:Version>7.0</crs:Version>
<crs:ProcessVersion>6.7</crs:ProcessVersion>
<crs:WhiteBalance>Custom</crs:WhiteBalance>
<crs:Temperature>5850</crs:Temperature>
<crs:Tint>8</crs:Tint>
<crs:Exposure2012>0.0</crs:Exposure2012>
<crs:Highlights2012>0</crs:Highlights2012>
<crs:Shadows2012>0</crs:Shadows2012>
<crs:Whites2012>0</crs:Whites2012>
<crs:Blacks2012>0</crs:Blacks2012>
<crs:Contrast2012>0</crs:Contrast2012>
<crs:Clarity2012>0</crs:Clarity2012>
<crs:Saturation>0</crs:Saturation>
<crs:Sharpness>25</crs:Sharpness>
<crs:LuminanceSmoothing>0</crs:LuminanceSmoothing>
<crs:LuminanceNoiseReductionDetail>50</crs:LuminanceNoiseReductionDetail>
<crs:LuminanceNoiseReductionContrast>0</crs:LuminanceNoiseReductionContrast>
<crs:ColorNoiseReduction>25</crs:ColorNoiseReduction>
<crs:ColorNoiseReductionDetail>50</crs:ColorNoiseReductionDetail>
<crs:ChromaticAberrationR>0</crs:ChromaticAberrationR>
<crs:ChromaticAberrationB>0</crs:ChromaticAberrationB>
<crs:VignetteAmount>0</crs:VignetteAmount>
<crs:ShadowTint>0</crs:ShadowTint>
<crs:RedHue>0</crs:RedHue>
<crs:RedSaturation>0</crs:RedSaturation>
<crs:GreenHue>0</crs:GreenHue>
<crs:GreenSaturation>0</crs:GreenSaturation>
<crs:BlueHue>0</crs:BlueHue>
<crs:BlueSaturation>0</crs:BlueSaturation>
<crs:Vibrance>0</crs:Vibrance>
<crs:Defringe>0</crs:Defringe>
<crs:ToneCurveName>Linear</crs:ToneCurveName>
<crs:ToneCurve>
<rdf:Seq>
<rdf:li>0, 0</rdf:li>
<rdf:li>255, 255</rdf:li>
</rdf:Seq>
</crs:ToneCurve>
<crs:CameraProfile>Adobe Standard</crs:CameraProfile>
<crs:LensProfileSetup>LensDefaults</crs:LensProfileSetup>
<crs:GradientBasedCorrections>
<rdf:Seq>
<rdf:li rdf:parseType="Resource">
<crs:What>Correction</crs:What>
<crs:CorrectionAmount>1.0</crs:CorrectionAmount>
<crs:CorrectionActive>true</crs:CorrectionActive>
<crs:LocalExposure2012>0.0</crs:LocalExposure2012>
<crs:LocalTemperature>0.0</crs:LocalTemperature>
<crs:LocalTint>0.0</crs:LocalTint>
<crs:LocalHighlights2012>0.0</crs:LocalHighlights2012>
<crs:LocalShadows2012>0.0</crs:LocalShadows2012>
<crs:LocalSaturation>0.0</crs:LocalSaturation>
<crs:LocalContrast2012>0.0</crs:LocalContrast2012>
<crs:LocalClarity2012>0.0</crs:LocalClarity2012>
<crs:LocalSharpness>0.0</crs:LocalSharpness>
<crs:LocalBrightness>0.0</crs:LocalBrightness>
<crs:LocalLuminanceNoise>0.0</crs:LocalLuminanceNoise>
<crs:LocalMoire>0.0</crs:LocalMoire>
<crs:LocalToningHue>230.0</crs:LocalToningHue>
<crs:LocalToningSaturation>0.0</crs:LocalToningSaturation>
<crs:CorrectionMasks>
<rdf:Seq>
<rdf:li rdf:parseType="Resource">
<crs:What>Mask/Gradient</crs:What>
<crs:MaskValue>1.0</crs:MaskValue>
<crs:ZeroX>0.5</crs:ZeroX>
<crs:ZeroY>0.6</crs:ZeroY>
<crs:FullX>0.5</crs:FullX>
<crs:FullY>0.2</crs:FullY>
</rdf:li>
</rdf:Seq>
</crs:CorrectionMasks>
</rdf:li>
<rdf:li rdf:parseType="Resource">
<crs:What>Correction</crs:What>
<crs:CorrectionAmount>1.0</crs:CorrectionAmount>
<crs:CorrectionActive>true</crs:CorrectionActive>
<crs:LocalExposure2012>0.0</crs:LocalExposure2012>
<crs:LocalTemperature>0.0</crs:LocalTemperature>
<crs:LocalTint>0.0</crs:LocalTint>
<crs:LocalHighlights2012>0.0</crs:LocalHighlights2012>
<crs:LocalShadows2012>0.0</crs:LocalShadows2012>
<crs:LocalSaturation>0.0</crs:LocalSaturation>
<crs:LocalContrast2012>0.0</crs:LocalContrast2012>
<crs:LocalClarity2012>0.0</crs:LocalClarity2012>
<crs:LocalSharpness>0.0</crs:LocalSharpness>
<crs:LocalBrightness>0.0</crs:LocalBrightness>
<crs:LocalLuminanceNoise>0.0</crs:LocalLuminanceNoise>
<crs:LocalMoire>0.0</crs:LocalMoire>
<crs:LocalToningHue>230.0</crs:LocalToningHue>
<crs:LocalToningSaturation>0.0</crs:LocalToningSaturation>
<crs:CorrectionMasks>
<rdf:Seq>
<rdf:li rdf:parseType="Resource">
<crs:What>Mask/Gradient</crs:What>
<crs:MaskValue>1.0</crs:MaskValue>
<crs:ZeroX>0.5</crs:ZeroX>
<crs:ZeroY>0.4</crs:ZeroY>
<crs:FullX>0.5</crs:FullX>
<crs:FullY>0.8</crs:FullY>
</rdf:li>
</rdf:Seq>
</crs:CorrectionMasks>
</rdf:li>
</rdf:Seq>
</crs:GradientBasedCorrections>
<crs:HasSettings>True</crs:HasSettings>
<crs:CropTop>0.0</crs:CropTop>
<crs:CropLeft>0.0</crs:CropLeft>
<crs:CropBottom>1.0</crs:CropBottom>
<crs:CropRight>1.0</crs:CropRight>
<crs:CropAngle>0.0</crs:CropAngle>
<crs:CropConstrainToWarp>0</crs:CropConstrainToWarp>
<crs:HasCrop>True</crs:HasCrop>
<crs:AlreadyApplied>False</crs:AlreadyApplied>
<crs:RawFileName>IMG_2483.CR2</crs:RawFileName>
</rdf:Description>
<rdf:Description rdf:about=""
xmlns:xmp="http://ns.adobe.com/xap/1.0/">
<xmp:Rating>0</xmp:Rating>
</rdf:Description>
<rdf:Description rdf:about=""
xmlns:lrt="http://lrtimelapse.com/">
<lrt:ReferenceBoxX1>0.0</lrt:ReferenceBoxX1>
<lrt:ReferenceBoxX2>1.0</lrt:ReferenceBoxX2>
<lrt:ReferenceBoxY1>0.0</lrt:ReferenceBoxY1>
<lrt:ReferenceBoxY2>1.0</lrt:ReferenceBoxY2>
<lrt:ReferenceKeyFrame>false</lrt:ReferenceKeyFrame>
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>
<?xpacket end="w"?>
Main Difference:
The Tags Version and ProcessVersion -> Guees these define how LR processes the XMP (2010 or 2012)
The Tags in the 2012 XMP File have 2012 added to their Tags (see Exposure)
So I guess a correct 2010/2012 XMP Version Template should have:
a correct header
a correct Version and ProcessVersion Tag
a correct Exposure/Exposure2012 Tag
correct foot
Try this (the template from audionut):
https://bitbucket.org/hudson/magic-lantern/commits/20120a144c74
I guess the AlreadyApplied tag was guessed from timestamps if it was missing?
ML, we have lift-off!!!!!!!!! ;D
commit 20120a1
Only change I see here is the maximum exposure should be 3.9999 and not 4.
So far 10 out of 10 could be read. Will test 50...
Compiled and shot 4 CR2 with AutoETTR
Seems OK for me in LR4, Exp value correct applied, Process is also 2012.
If someone else confirms --> SOLVED :)
THANK YOU !!
EDIT: Realized Renato has confirmed !
I shot a few more... missed some!
Why, i don't know. After running all through UFT-8 converter they are all working.
So I am not getting consistent results?
Got the process 2012 working. But it's still being a pita with accepting some XMP's.
Tried a bunch of other tags too, but it made no difference.
I think a1ex is going to have to delay the file creation and see what that gets us.
A hell of a lot of stuffing around for what appears to just be a file creation tag.
Quote from: RenatoPhoto on June 05, 2013, 08:03:57 PM
ML, we have lift-off!!!!!!!!! ;D
commit 20120a1
Only change I see here is the maximum exposure should be 3.9999 and not 4.
So far 10 out of 10 could be read. Will test 50...
Also correcting myself, again. ACR will read +4 or -4. When I made the test of 3.999 I saved the file and that was enough to make it work. In reality the file was just not being read to begin with. Therefor I had failure from the beginning.
I suck as a tester sometimes. :'(
Quote from: Audionut on June 05, 2013, 08:44:02 PM
I think a1ex is going to have to delay the file creation and see what that gets us.
Or, rightfully so, he'll make me do it. I believe the term is "code monkey"!
I got it working for me, but I'd like some others to test it also before we end up with another fix in the commit log to satisfy adobe.
edit: Removed redundant code.
I fired off a few shots reasonably quickly and they all worked. But no significant testing as yet. Might even be able to reduce the wait time further. You can notice the 500ms delay.
edit: tried 100ms delay and got 2 out of 12 not working. 200ms delay seems to be the ticket.
Quote from: RenatoPhoto on June 05, 2013, 08:44:36 PM
Also correcting myself, again. ACR will read +4 or -4.
Is this process 2010. Exposure values +-5EV work fine here with the new XMP's and process 2012.
Quote from: Audionut on June 05, 2013, 09:29:41 PM
Is this process 2010. Exposure values +-5EV work fine here with the new XMP's and process 2012.
another testing failure. I must have been using the 2010.. I tested again on your find and yes I can slide to +5 or -5 when I have the correct and latest profile.
Sweet.
Just to confirm a1ex. Don't need the AlreadyApplied tag.
Found something: http://forums.adobe.com/message/5208053
QuoteThere has been a bug, not sure in LR or PS, where if the XMP file date is BEFORE the raw-file date, then the XMP is ignored so maybe that could be happening.
I would prefer to avoid the delay hack, because it happens in a Canon task and will slow down image review and who knows what else. The proper way to do it would be to offload it to a ML task.
Hmm, I think I know what I missed.
When adding those XMP date tags, it probably wants these bloody things too
xmlns:xmp="http://ns.adobe.com/xap/1.0/"
xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/"
Give me a sec.
No good. It's ignoring those XMP date tags. I can take a hex editor to the CR2 files and adjust their date early and it still makes no difference.
I am perfectly ok with using the uft-8 converter. It is so tiny and easy to use in windows.
@ Audionut Do you know of a program that could add or subtract exposure values to the XMP files (many at once). I want to generate three files with different exposures so that I can merge them to HDR. In the past I had no problems with ACR but now each image has a different exposure so it cannot be done quickly in ACR. Maybe an option in ML to generate three different XMP?
I can't think of one off the top of my head.
I'm positive I don't understand exactly what you're trying to do.
You're not trying to generate 3 exposures from the 1 raw file right? That's not hdr.
I don't understand the problem your having with exposure values in acr. Can you explain it better for me?
Since the dynamic range and color depth is so good in RAW, I have cheated before where I take one .CR2 image and export it out of ACR at three different exposures. Later I use Photomatix Pro to generate a very nice HDR. I have also done this with Timelapse images by importing them to ACR and generating the three exposures which are then batch joining them, three at a time, to make a pseudo HDR Timelapse. This works pretty good...
Now with these .CR2 files, each one has a preset exposure that make the Timelapse Flicker Free.. The problem I have is now to raise say 1 EV to all images, then export them, then lower exp by -2 EV, then export them. Finally I merge the original with the +1, -2 to make new HDR image. So I need a software that take the current corrected exposure and change all of them at the same time or via a script.
Maybe LRTimelapse can do this but I have not used it before.
Ah, I see. Just to be clear, that's not HDR. You can't increase the dynamic range of 1 file. Yeah, I know there's heaps of progs out there that market it as such, but their lying. You're only working with the dynamic range of that original file. I think that process is more accurately called tone mapping (not 100 % sure on the correct terminology). Anyway, I'll stop being me now.
If you can find something that can batch edit the value (eg: -1EV from current value), you could copy the XMP's twice, and batch edit each set with a different EV based on the original. But honestly, I don't think you're going to have much luck unless you can find someone who can write something new with that process in mind.
edit:
My best guess would be the ExifTool by Phil Harvey (http://www.sno.phy.queensu.ca/~phil/exiftool/) with the ExifTool GUI (http://u88.n24.queensu.ca/exiftool/forum/)
Not sure if it will do exactly what you want. But if your register on the forums over there, you might be able to convince the devs to make the changes you need, or find better information on the process at least.
I AM LOST!! 5D3 commit cecbc21d
ACR reads most files but fails 3 out of 20 aprox.
But the big problem is that when I used the utf-8 converter.. Now ACR cannot read any of them! So now I have no FIX!
Just to make sure I tested ACR with previous xmp from june 3, 4rth, and 5th. And it works as expected utf-8 converter always fixed the issue.
Just to make sure I formatted SD card and reinstalled ML. No change..
Just to make sure I re-loaded Canon FIR 1.1.3. No change..
I tried changing the format as previously with notepad+++ No change
I tried copying the old text format from working versions... No change
I tried previous commits form 5th, 4rth, 3rd. No change, ie cannot open files when I process with utf-8converter.
Now I simply cannot read reliably the XMP.
Something changed in the camera itself and cannot be reverted back to the way it was. I did have a crash and had to enter the date and time zone again, maybe that has something to do with it?
And I can confirm the same problems with Adobe Lightroom 4.2.
Can anyone else test these xmp files and report any issues? I am working on windows 7 - 64 bit
Thanks
No problems here with code a few revisions before yours. And doesn't appear that there was any changes that effected XMP's.
I'll double check again a little later with the latest revision, when it looks like a1ex has slowed on pushing fixes and updates.
Still no problems here RP.
Quote from: RenatoPhoto on June 06, 2013, 05:39:45 PM
ACR reads most files but fails 3 out of 20 aprox.
How is "fail" specifically? Does it fail silently (ignoring the xmp) or does it return an error message? ACR (Lightroom 4 & 5) seems to have no issue with all xmp files here, maybe I'm just lucky.
No error, it simply ignores the exposure compensation. At the beginning I use to just run all of the xmp files through a little converter and I got 0% percent problems. After the last change now I cannot get 100% read nor can I process them through the converter, because then it ignores them all and I cannot get ACR to read them no matter what I do. It is very strange. Even if I use some older compile, I can not get them to work. I appears that something happened to my camera in the process.
Have you been playing with the source?
Just to confirm, your XMP's are like this,
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Magic Lantern">
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about=""
xmlns:crs="http://ns.adobe.com/camera-raw-settings/1.0/"
crs:ProcessVersion="6.7"
crs:Exposure2012="+0.42237"
crs:AlreadyApplied="False">
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>
Thanks for the info. It is the same format. I am absolutely sure that something changed in the camera.. there is no question in my mind. The problems is that I dont know how to get it back to what it was before.
The anti XMP virus has come my way!! I can process the ufraw files but xmp is not read all the time by ACR.
The really strange thing is that if I touch the xmp files in any way then they 100% fail in ACR. I use to be able to open them in notepad, notepad+++, excell and change settings. Now if just open them and save then then ACR will not read them at all!!
Maybe something changed in the CR2 file itself?
It won't be the XMP's then, in the sense that the data contained is correct. I can input crap data and ACR won't read, but as soon as I remove the offending data, ACR will read them fine again.
What color space are you setting in camera? AdobeRGB will change the first character of the CR2 files as compared to setting sRGB color space in camera.
_46A0001.CR2
D46A0001.CR2
I use Adobe RGB i.e. _xxxxx
Even if i roll back to the builds where I could modify xmp, the camera now puts out new xmps that I cannot modify in any way.
Switch the camera to sRGB. If you only shoot raw photos it's just a flag that gets ignored in ACR.
Eureka! Problems with XMP solved
I can now modify my xmp files. My camera was set one hour ahead of my computer time. Anytime I messed with xmp the edit time was set 1 hour earlier then the created time and ACR would not read the files.
I can now read my xmp files in ACR 100% of the time. I had an issue with the Bulk Rename utility because I was modifying the name of the CR2 file. This put a modified time stamp on this file which was later then the XMP file. Now I rename my xmp files and also use the option in Bulk Rename Utility to set my time stamp of Date Modified to Current Time.
LEARNED LESSON No 1: Make sure your camera time is not ahead of the computer time.
LEARNED LESSON No 2: If the name of your CR2 file does not agree with the xmp, change the XMP always. In this manner the xmp will be modified after the CR2. If you do it the other way ACR will not read the files.
Quote from: RenatoPhoto on June 13, 2013, 04:40:18 PM
Eureka! Problems with XMP solved
... but by manually "touch"ing the files, here's a better solution - I created a dedicated bug ticket since I don't think this belongs in a "q&a" thread: http://www.magiclantern.fm/forum/index.php?topic=6468.msg50708#msg50708
Quote from: RenatoPhoto on June 13, 2013, 04:40:18 PM
Eureka! Problems with XMP solved
I can now modify my xmp files. My camera was set one hour ahead of my computer time. Anytime I messed with xmp the edit time was set 1 hour earlier then the created time and ACR would not read the files.
I can now read my xmp files in ACR 100% of the time. I had an issue with the Bulk Rename utility because I was modifying the name of the CR2 file. This put a modified time stamp on this file which was later then the XMP file. Now I rename my xmp files and also use the option in Bulk Rename Utility to set my time stamp of Date Modified to Current Time.
LEARNED LESSON No 1: Make sure your camera time is not ahead of the computer time.
LEARNED LESSON No 2: If the name of your CR2 file does not agree with the xmp, change the XMP always. In this manner the xmp will be modified after the CR2. If you do it the other way ACR will not read the files.
Have you tried XMP files that are now generated for silent pics? I shot a timelapse using intervalometer + silent pics... the XMP files were generated but ACR, Lightroom, or After Effects didn't seem to pick up the exposure adjustments from the XMP. This is a very new commit so I'm not sure if it's just me or something that doesn't function properly when the files are DNG+XMP.
https://bitbucket.org/hudson/magic-lantern/commits/92fa76fb870df73fe8fc440c9de0f63d9af76589 (https://bitbucket.org/hudson/magic-lantern/commits/92fa76fb870df73fe8fc440c9de0f63d9af76589)
EDIT: I now see that this is a small problem with the XMP code which Audionut just identified.
There was still a bug in the XMP code. It should be fixed now. It's working for me.
hi all, and sorry if i'm off topic, but i've readed all in the forum about xmp deflicker without solving my issue.
basically my problem is that the exposure compensation calculated and displayed on liveview when i shoot a timelpse with ettr and delickering activated is alway way over the +4/-4 range. so my xmp is full of +3.99 compensation intead of the correct one. tried all the cominations of ev in deflicker, and also in ettr but cannot have correct exp compensation.
if it' not clear i can post some combinations of settings i use
Can you delete the ML config file and the config files from the module folder and try again with default settings.
If it still seems to be broken for you, can you post a CR2/DNG with associated XMP.
Think i've resolved ;)
http://youtu.be/VOvp5imv-g8
wow guys, this new Method For day\night timelapses is better t'han every Method i've used before, very stable deflickering and ettr is pretty useful, Great work guys
Alex, I just shot a sunset timelapse using the combination of ML intervalometer, silent pics, XMP post deflicker, and Auto ETTR (always on). This combination works really well, with the bonus of saving shutter actuations. The only thing I did notice is that in the 25 second timelapse I did, there were 6 specific frames (mostly spread out) that the exposure adjustments were off, causing noticeable flicker in those 6 spots. I had to manually correct those frames. I didn't use an ND so my shutter was at 8000 to start, eventually dropping to 640, than 360, and ISO remained constant at 100 till the end. I have a feeling that the 6 times where the XMP exposure adjustment were off may have corresponded to same moments when the shutter needed to change due to Auto ETTR. I just can't be sure without having a way to match the drops in shutter speed to the incorrect XMP exposure adjustments. Since shutter, ISO, etc. are not written to the DNGs, maybe both shutter and ISO can be written to the XMP. With that, I would be able to verify my theory.
Edit: Here's the timelape I did with the 6 frames already corrected. No flicker... pretty much auto mode for timelapses.