Author Topic: [SOLVED] POST DEFLICKER with XMP (Read 32705 times)

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

Iam using latest nightly build + Tragic Lantern 2.0 + 600d

baq

RenatoPhoto · « **Reply #1 on:** May 27, 2013, 03:11:56 AM »

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.

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

Baquster · « **Reply #2 on:** May 28, 2013, 01:29:24 AM »

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!

Audionut · « **Reply #3 on:** May 28, 2013, 02:44:34 AM »

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.

RenatoPhoto · « **Reply #4 on:** May 28, 2013, 04:58:53 AM »

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.

RenatoPhoto · « **Reply #5 on:** May 28, 2013, 03:17:52 PM »

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

Baquster · « **Reply #6 on:** May 28, 2013, 10:04:13 PM »

Is there a solution for mac ?

a1ex · « **Reply #7 on:** May 28, 2013, 10:05:36 PM »

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.

RenatoPhoto · « **Reply #8 on:** May 28, 2013, 11:32:45 PM »

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.

a1ex · « **Reply #9 on:** June 04, 2013, 07:14:34 PM »

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

Audionut · « **Reply #10 on:** June 05, 2013, 01:43:29 AM »

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 of some XMP's if you want to have a look at them.

2623, 2626, 2627, 2628 are the ones that work.

RenatoPhoto · « **Reply #11 on:** June 05, 2013, 02:39:53 AM »

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

Audionut · « **Reply #12 on:** June 05, 2013, 03:20:37 AM »

That does indeed fix it.

A zip with original XMP and fixed XMP with the prog above.

RenatoPhoto · « **Reply #13 on:** June 05, 2013, 02:49:25 PM »

Quote from: Audionut on June 05, 2013, 03:20:37 AM

That does indeed fix it.

A 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.

a1ex · « **Reply #14 on:** June 05, 2013, 02:57:44 PM »

Even at binary level, the two files are identical.

Maybe it's the timestamp?

Audionut · « **Reply #15 on:** June 05, 2013, 03:06:15 PM »

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.

jbuy41 · « **Reply #16 on:** June 05, 2013, 03:10:02 PM »

Alex, what software do you use?

a1ex · « **Reply #17 on:** June 05, 2013, 03:26:07 PM »

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

Audionut · « **Reply #18 on:** June 05, 2013, 03:31:07 PM »

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.

a1ex · « **Reply #19 on:** June 05, 2013, 03:48:34 PM »

Okay, so in ML I should delay the file creation by one second?

Audionut · « **Reply #20 on:** June 05, 2013, 03:52:58 PM »

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?

RenatoPhoto · « **Reply #21 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.

RenatoPhoto · « **Reply #22 on:** June 05, 2013, 04:13:35 PM »

As as test I just opened the files in notes and close them, with the new date stamp all are recognized by ACR

a1ex · « **Reply #23 on:** June 05, 2013, 04:17:53 PM »

Well, send me some sample files from 2012 or whatever is recent.

It's not working anyway for burst pics.

Audionut · « **Reply #24 on:** June 05, 2013, 04:22:39 PM »

https://dl.dropboxusercontent.com/u/34113196/ML/D46A2620.XMP

News:

Author Topic: [SOLVED] POST DEFLICKER with XMP (Read 32705 times)