• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5

Strange error happening to several sequences.

Offline
#11 jorn-t
It happened again. I was editing the sequence "001 Mount Whitney Valley View", then while visual previews were updating, changed to folder "005 Long Mountain Shake", and chose "Yes" to add visual deflicker in the background. Without doing anything to the second sequence, those .xmp appeared in the folder, and made a mess of the sequence.
Attached Files
Thumbnail(s)
   
Offline
#12 Gunther
Did you follow my advice to rename the images?
Subscribe to: LRTimelapse Newsletter, Youtube Channel, Instagram, Facebook.
Offline
#13 jorn-t
I am in the process of completing editing of 200 timelapse sequences, and I do not intend to rename all those files because of a bug in LRTimelapse..  

Anyway, the bug still happens pretty often. After a few hours of work, .xmp files from one sequence appears in the folder of a different sequence, and it seems that when this error happens, it seem to happen to all folders I work with, until I restart LRTimelapse.

For instance, all the xmp files IMG_1053.xmp - IMG_1352.xmp from sequence "012 Golden Gate Sunset" appeared in the folder "013 Golden Gate After Sunset" where IMG_6568 - IMG_6736 resides. And the folder "012 Golden Gate Sunset" also had all the .xmp files from folder "011 Sunset 2" and so on.

No .xmp files were overwritten in those cases, since my two cameras were in the 1000-2000 and 4000-6000 numbers respectively. But still, deflickering was not working as expected, and I had to restart LRTimelapse, then reset deflicker on all sequences and start new deflicker, one at a time, to get good results.

For instance, look at this sequence which had undergone a 5-pass deflicker (attached image). I suspect LRTimelapse uses .xmp files from a different sequence when doing visual previews, or something.

   
Offline
#14 Gunther
It's most likely only the previews that get mixed up if you are working on folders at the same time which have images with equal names.
I recommend to always rename the images from the camera to have unique names. This will prevent many problems, not only with LRTimelapse.
Is recommend to always rename the images when importing chia the LRTimelapse importer. It's one click that will save you trouble.
On sequences that you already imported, just press F2 to rename.

Posted mobile via Tapatalk...
Subscribe to: LRTimelapse Newsletter, Youtube Channel, Instagram, Facebook.
Offline
#15 ianm
I just registered to mention that the date issue is still happening in v5.0.6 (free). It's rewriting them to 2017-09-14
Another thing happening is it's ignoring my white balance settings and rewriting it's own every time.

I loved v4 of this program (easy to use, no bugs), even though I've only used it a handful of times. Shame this was a forced upgrade. Then again, since I haven't paid for it, I don't have too much to complain about, just pointing out that these problems still exist.
Offline
#16 Gunther
LRTimelapse is rewriting your image dates? Seems quite impossible to me. When exactly do you think this is happening?
Regarding White Balance: Which type of images are you using? Try changing the White Balance Treatment in the Metadata Menu to the other option and try again. Some cameras do not specify which type of data they store inside of their DNG files. This also applies to GoPro Raw files for example.
Subscribe to: LRTimelapse Newsletter, Youtube Channel, Instagram, Facebook.
Offline
#17 ianm
Sorry - rewriting may be the wrong term. Misreading then? Either way, it puts the images out of order and makes me think that it's getting the luma changes wrong. Playing around with it, I've noticed changes when loading up the program. Reloading the metadata in LRTL fixes it, but saving goes back to the error date.

As for the white balance changes, yeah, it's ignoring any changes made in Lightroom and applying the same settings over and over. Since I'm keeping the WB the same throughout, it's more an annoyance than anything. Still thought you should know.

[Image: http://ianmcdonnell.com/lrtl5/lrtlscreen.jpg]


As you can see from the shot, file DJI_0216.DNG and 217 are out of order due to them having the correct date. All other files have the same incorrect date read. 128 should be first - this was a 1-keyframe setup.
Offline
#18 Gunther
As you can see, the saved keyframes have the time in the Date/Time field, the others not. Most likely your camera (I still don't know which one this is) writes a wrong date/time format, so that either Lightroom or LRTimelapse discards the time information. Of course this will then mess up the ordering.

I suspect this being a Chinese Kamera from Mi or similar, they are known for messing the Exif Data up.
This is not a LRTimelapse problem, all cameras that obey the standars, are correctly supported.

But if you send me a sample image, I can check and see what's going on and if I can possibly provide a work around.
Please send the image via https://fromsmash.com/ to support(at)lrtimelapse(dot)com.

Regarding the Whitebalance: I've already told you how you can fix it. In the Metadata Menu change the "Whitebalance Treatment" to the opposite value. Also this happens due to missing information in the camera's Exif-Data.
Subscribe to: LRTimelapse Newsletter, Youtube Channel, Instagram, Facebook.
Offline
#19 ianm
Thanks for the white balance info. It was indeed set for jpg.

As for the files dates, Lightroom seems to be reading them correctly. Rather than speculate on the reasons, I'll upload a raw file for you to check. The camera is indeed Chinese - a DJI Mavic Air, though not sure what camera specifically they put on that drone. Haven't had a chance to test LRTL5 with my slr yet, so that's all I've got for you.

It's a little strange that the files change dates, and your software is able to read the correct times after I tell it to reload. But you're the programmer - I'll send you the file and wait for your answer.

eta: I suspect the workaround will be to save exif data in LR before opening the files in LRTL, which I'm happy to do - just a quick step.
Offline
#20 Gunther
I've checked your sample image, and indeed before LRTimelapse loads the exifdata, there seem to be only the date given.

But: if you follow the LRTimelapse workflow, by starting loading the fresh sequence into LRTimelapse, LRTimelapse will correct the Date/Time ExifData. Now go through the first row in LRT, and finish with saving. This should establish correct date/time data for the whole sequence. In my tests, Lightroom didn't alter those. Now edit the keyframes in Lightroom, save Metadata for those and go back to LRTimelapse. After Reload, you should still have the full Date/Time info for all images.

Bottomline: it's important to do the workflow exactly as intended, always start in LRTimelapse. Don't start editing in Lightroom.
Subscribe to: LRTimelapse Newsletter, Youtube Channel, Instagram, Facebook.

...also check out: