5 Messages
•
126 Points
Sun, Mar 18, 2018 8:36 PM
BUG: LRCC IOS assigns an arbitrary filename unrelated to the camera's name
When uploading JPGs to LRCC/IOS, LRCC assigns an arbitrary filename that is unrelated to the name assigned by the camera. This makes it very difficult to match the image with the RAW file which I upload later as these cannot be transferred over wifi.
I transferred JPGs to my iPhone 8 from my Sony a6300 camera, using Wifi and the Playmemories IOS app; then I imported these to LRCC/IOS (v. 3.1.2 EC011D running MacOS 11.2.6). This allowed me to utilize the images on social media while traveling. When I got home I synced LRCC/IOS with LRCC Classic/MacOS (v7.2, on MacOS 10.13.3), hoping to then perform the same edits on the RAWs whose JPGs I had liked best. But the names of the JPG files were of the form IMG_nnnn, where nnnn was 1545 or 1546 greater than the corresponding Sony-assigned number.
Yikes! That makes it extremely painful to locate and use the RAW corresponding to a given JPG in LRCC Classic.
I confirmed that the name of the JPG in LRCC Classic/MacOS is identical to that on LRCC/IOS. So the name change is clearly happening in LRCC/IOS.
I also confirmed that the JPG files as uploaded to Photos/IOS have the Sony-assigned number (the names are of the form ORG_DSCmmmmm.jpg, where mmmmm is the number of the file as it appears on the SD card written by the camera (form DSCmmmmm.jpg). I confirmed this by sharing a file out of Photos/IOS and selecting the Files app as the recipient; the name proposed was of the ORG_DSCmmmmm.JPG form, with the number matching the SD card.) They also transfer correctly in Google photos. But I did a ton of editing and rating on them in LRCC/IOS. I thought that was the point of the product.
BTW I do realize I can probably avoid the problem by buying an SD card reader and importing files to IOS that way. And I've ordered one, now that I've read about it. But I feel this should work right! Otherwise this behavior is like a hidden boobytrap.
Thanks,
Charlie
PS I originally posted this as a question in the user forum; here's the thread (with advice to repost as a bug:-) https://forums.adobe.com/message/10251695#10251695
I transferred JPGs to my iPhone 8 from my Sony a6300 camera, using Wifi and the Playmemories IOS app; then I imported these to LRCC/IOS (v. 3.1.2 EC011D running MacOS 11.2.6). This allowed me to utilize the images on social media while traveling. When I got home I synced LRCC/IOS with LRCC Classic/MacOS (v7.2, on MacOS 10.13.3), hoping to then perform the same edits on the RAWs whose JPGs I had liked best. But the names of the JPG files were of the form IMG_nnnn, where nnnn was 1545 or 1546 greater than the corresponding Sony-assigned number.
Yikes! That makes it extremely painful to locate and use the RAW corresponding to a given JPG in LRCC Classic.
I confirmed that the name of the JPG in LRCC Classic/MacOS is identical to that on LRCC/IOS. So the name change is clearly happening in LRCC/IOS.
I also confirmed that the JPG files as uploaded to Photos/IOS have the Sony-assigned number (the names are of the form ORG_DSCmmmmm.jpg, where mmmmm is the number of the file as it appears on the SD card written by the camera (form DSCmmmmm.jpg). I confirmed this by sharing a file out of Photos/IOS and selecting the Files app as the recipient; the name proposed was of the ORG_DSCmmmmm.JPG form, with the number matching the SD card.) They also transfer correctly in Google photos. But I did a ton of editing and rating on them in LRCC/IOS. I thought that was the point of the product.
BTW I do realize I can probably avoid the problem by buying an SD card reader and importing files to IOS that way. And I've ordered one, now that I've read about it. But I feel this should work right! Otherwise this behavior is like a hidden boobytrap.
Thanks,
Charlie
PS I originally posted this as a question in the user forum; here's the thread (with advice to repost as a bug:-) https://forums.adobe.com/message/10251695#10251695
Problems
0
0
Helpful Widget
How can we improve?
Tags
No tags available
Responses
No Responses!