Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[b_gossweiler]

By reading another post in the U2U forum, I just noticed that LR 3 Beta 2 does not provide for Exif data (e.g. Camera Serial, focal length, ISO etc.) to be used as tokens at import time anymore.

Does anybody know why these tokens present in LR 2 were dropped (or where I could find them)?

Beat

[TNG]

Beat,

Never noticed before (as I don't tend to do anything beyond adding the date to my filenames on import). Using the file rename option in the Library does give you a Filename Template Editor which includes the option to add various Metadata fields as tokens, but not quite as good as doing the rename on import, I guess.

[b_gossweiler]

Jim,

I even tried to create a custom template in the filename template editor in Export, which gives you those options also, and use it in Import. But the non-existant tokens at Import are just ignored from the template, when applied at Import time.

Beat

[sizzlingbadger]

I have already sent in a bug report for this. I used Serial Number and it has disappeared during import depite my file name preset actually containing it.

[longstag]

Now with first final release it got not really better.
I try to use Exif data for import like this example:

YYMMDD_hhmmss_EOS450D_$ORIGINALNAME

If I choose it for the import the filename is +2h to the capture time.
If I don't rename during the import and rename it later with "Library --> Photo rename" it works with the right time.
Could somebody verify and agree with me?

I'm using LR3.0 on a MAC OSX 10.6.4

[TNG]

Hi longstag, welcome to the forum.

I think this issue has already been reported as a bug to Adobe, though you can always file your own using the link in the blue bar at the top of the page. I have just tried it, and confirm the similar result...though in my case it is adjusting the hour by +1 (I am in the UK so my clocks are now GMT+1). It would seem that when renaming on import, and adding the hour value to the filename, that Lightroom is assuming the time in the camera when the picture was taken was set to GMT, not local time. It then "corrects" the hour to match the local time value in your computer.....mine is BST, hence it adds one hour. I assume you are in a CET area, which is currently GMT+2, so your filename gets 2 hours added to it.

Does that make sense.....

[Victoria Bampton]

Yep, unfortunately the date bug didn't get reported until after the final release, but they are aware of it.  For now, import and then rename in Library will solve the problem.

[Denis Pagé]

Import then rename in library didn't worked for me! 

I discovered a variant of the bug plus two others in the same operation and a fourth trying to correct the problem! Will report to Adobe as these seem new to me...

Didn't had time to put LR3 to work before today but as I noticed this thread when it appeared, I was closely inspecting the import behaviour. This broke my workflow and is really a show stopper. 

As I geolocate with Geosetter and it is making backups of the DNGs before rewriting them with the XMP data, I now prefer to just copy my raw files to the computer (NEF in my case) and geotag them so it only creates XMP sidecar files so much faster than rewriting DNGs. Only then I import in Lightroom converting to DNG.

But this time I imported the raws first, to geotag later overwriting metadata when back to take the new data in. This worked as usual BUT! As I used my normal rename template at import which is {Date (YYYMMDD)»}_{Filename number suffix»} AND that in "Destination" I choose "Organize" "By date" with a "Date Format" and I expected 2010/2010-06-26 as the proposed model but got 2010/26-06-2010 as folder name and I got the files renamed 26062010_nnnn as file names!

If I did continue to import it is because in LR 2.6 and before, it was showing a wrong example but was importing correctly. You don't see this behaviour? Normal as most of you are using Lightroom in english but this time I was using it in french as I am a switcher to give support in both languages and I also switch from Windows to Mac (From laptop to desktop).

Thinking as per this thread that I can probably rename later I went ahead and keyworded and such... Then Ctrl-S to save to XMP for later conversion to DNG. The conversion to DNG went on and I opted to KEEP the NEF-XMP pairs just in case (as i normally don't). But the DNG conversion added a "-1" suffix being in the same folder  as the NEF-XMP pairs equivalents were still there! I opted to delete those DNGs from both catalog and disk and reimport the NEF-XMP pairs BUT BEFORE DOING SO I took care to switch Lightroom to english! Then the second bug!

As the NEF-XMP pairs previously imported in the wrong folder structure and that this time the expected 2020/2010-06-26 folder structure and 20100625_nnnn was showing, I choose to import the pairs converting to DNG. Lightroom was showing in the import box dialog center: "Copy as DNG" with the note "Convert to DNG in a new location and add to catalog" under it. So I tought that my NEF-DNG pairs were going to be kept safe (just in case again) but after the conversion that went fine this time with expected folder and proper renaming, I discovered to my stupefaction that both the original 2010/26-06-2010 folder and the NEF-XMP pairs disappeared! I saw no option to keep originals there or I badly missed it. In any case, the CF card is not erased yet so... 

Now on to the third bug. Back to french version I looked again to customize my renaming template used above and discovered that when Lightroom is sitched to french the date is shown with {Date (JJMMAAA)»} and that there are no more "ANSI Date" options! The only option was to remove this date sheme to replace it with
{Date (AAAA)»}{Date (MM)»}{Date (JJ)»} hoping for the best the next time.

What about a fourth bug then?  Here we go:

Once I edited the template to use those three codes rather than one as before, I had no option to either overwrite my template or erase it to recreate again. I was stuck creating a new one keeping the previous (now useless) one.