Jump to content

lintujuh

Members
  • Content Count

    411
  • Joined

  • Last visited

  • Days Won

    26

lintujuh last won the day on November 16 2018

lintujuh had the most liked content!

Community Reputation

31 Excellent

About lintujuh

  • Rank
    Gold Member
  • Birthday May 12

Profile Information

  • Gender
    Male
  • Location
    Tampere, Finland

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I have some images that have extra short exposure time (1/6400s or 1/8000s), but Daminion shows them as 1/5000s. -Juha
  2. My mistake, I didn't test with the local catalogs, I only tested with server catalogs. The internal representations are different for server and local catalogs for date/time and that caused my program to fail. The fixed version is now in github. I cannot help you with the actual time difference. The only tip I have is that you check with ExifTool (in Daminion show all meta data) the date/time fields. -Juha
  3. Hi, I have also pointed this two years ago. I think we should also discuss the pros and cons, if for the creation time there would be an exception and that would also be updated in the RAW file itself. Many tools (e.g. RAW editors may use the EXIF data as the primary source) and then the non-updated creation time would be reflected into JPEGs or other end results. -Juha
  4. HI Uwe, I fully agree with you, milliseconds shouldn't be lost. I tested with some of the images that had lost their milliseconds and read tags from file didn't add the milliseconds into the database. -Juha
  5. I was debugging my DamCompare tools based on Egon's report on false positives in creation time. Based on my test cases, my conclusion is milliseconds are imported into database, even though they are not visible in GUI if you update creation time in Daminion, the milliseconds are dropped from database, but they remain in EXIF data I don't need the milliseconds in GUI, so the first bullet point is fine. They could still be important for sports or wildlife photographers shooting in continuous mode, so other users might want to see also them. The second bullet point is IMO breaking the key principle in Daminion that the data in database equals to data in the image. -Juha
  6. Hi Egon, Like Wilfried said, if you export your tags into a CSV and then import them into another catalog, there should be no difference. The purpose of the tools is compare the contents of your catalog to the tag values actually written into the images. When you create a new catalog and add your images there Daminion reads the tags in your images and recreates the database. My tool then compares the original database with the new database to detect differences i.e. tags that have not been written to the images. The difference in creation time is a "false positive". If you change the creation date in Daminion, Daminion stores the time in database without milliseconds. The milliseconds are still in the image's EXIF data and will be read into database, when you add the image. I think in your case this has happened the other way. When you created your export CSV, the milliseconds were dropped from there and they were not in your new catalog. My tool then detected the difference in milliseconds and reported it. I have fixed the issue and pushed an updated version to github. The updated version ignores the milliseconds in the comparison. There can still be reported differences in creation time as I have pointed out in thread -Juha
  7. Thank you Wilfried, Exactly as Wilfried said, the tool just compares two existing catalogs with each other, it doesn't import any images. Juha
  8. Hi Egon and sorry for the delay. The error message says that it finds DSCF2665.jpg in oldcat, but doesn't find it in newcat. You can try to add flag -f (means print full path) to your command line, if that gives you any hint. The program matches images in the catalogs with the full directory path and filename. Ask more, if this doesn't help. -Juha
  9. Haave you checked what exiftool reports? You can e.g. use actions > show all metadata. Juha
  10. Hi Rene, If you create a new catalog, I recommend to use my tool DamCompare (available in GitHub) to verify that your new database is equal to the old one. -Juha
  11. Hi! I don't know if this is related, but when I import DNG images from my mobile phone Daminion reads the exposure information correctly. But when I add geolocation with GeoSetter and re-read the tags from the image the exposure information is no longer visible in Daminion even though exiftool shows the information. I have uploaded an screenshots before and after and the DNG file before and after in my Dropbox. -Juha
  12. Or you can select from the Tags pane the Collections/Events/... and the first entry in the category is Unassigned. -Juha
  13. Hi Wilfried! Do you remember, has it been random also for the top level tags in hierarchical tags? Or could that be the root cause? I have only noticed this single instance. -Juha
  14. You can check which databases are used in your Daminion setup in Daminion Server Admin > Catalogs. There is also possibility to delete a database from disk in the commands. If your database is not listed in Server Admin, then Daminion doesn't know about it and it could be deleted in Postgres. When I got my new PC I copied over only those databases I know I wanted. -Juha
  15. I decided to restructure one branch in Events and create sub-tags. I moved all items from the root to one created branch and added items into another branch. Then I noticed that the top-level name was no longer correct and I renamed it. The change was only reflected in the database, but not written into the items. -Juha
×
×
  • Create New...