Jump to content

All Activity

This stream auto-updates     

  1. Past hour
  2. Hello together, Juha, it runs. Uwe, I think it's the import time stamp to the old catalog.
  3. Today
  4. Yesterday
  5. Hi Egon, my question: does the time stamp above correspond to any other date/time metadata in the file (file creation date, File Modification Date/Time, etc) imported to the new catalog? Regards, Uwe
  6. 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
  7. Hello Juha, thanks for the explanations. But the difference does not come from the milliseconds. Example: old catalog: 18.12.2009 17:48:43, new catalog and file: 15.03.2017 17:43:22. I have no idea where the difference is coming from. I have test your new script and I got errors: C:\Users\wir\Documents\Daminion\DamScan\DamScan-1.5.1>python DamCompare.py -f -l -c1 "C:\Users\wir\Documents\Daminion Catalogs\DaminionCatalog_ganz neu.dmc" -c2 "C:\Users\wir\Documents\Daminion Catalogs\CatNeu_2.dmc" -o out.txt Traceback (most recent call last): File "DamCompare.py", line 288, in <module> main() File "DamCompare.py", line 279, in main ScanCatalog(catalog1, catalog2, session, VerboseOutput) File "DamCompare.py", line 233, in ScanCatalog compare_image(curr_img, img2, session) File "DamCompare.py", line 194, in compare_image same, tags = img1.image_eq(img2, session.dist_tolerance, session.alt_tolerance) File "C:\Users\wir\Documents\Daminion\DamScan\DamScan-1.5.1\Daminion\DamImage.py", line 229, in image_eq self.creationtime = self.creationtime.replace(microsecond=0) TypeError: replace() takes no keyword arguments C:\Users\wir\Documents\Daminion\DamScan\DamScan-1.5.1> Whats wrong?
  8. Hi guys, I will bring my colleagues to this dialog so that they could take a look at it and fix the issue. Unfortunately, I cannot tell you when exactly it will be fixed kind regards, daria
  9. Update: I found the reason: this is my folder structure: Drive X: Daminion thumbnails Test (name of the catalog) 0 ... F (here are the thumbnail folders and the thumbnails created by Daminion) midsize preview Video (here are the video previews, set in the Admin Panel->Catalogs->Actions->Edit->Folder to store video previews) The action Catalog Optimize deletes the Video folder. But, if the folder Video is not a subfolder of the folder ...\Test -> Catalog Optimize doesn't delete the Video folder. A long way to find the reason. Now it has to be fixed or a check that the Video folder may not be a subfolder as shown above. regards, Uwe
  10. Hi. yes but which way we should go? Change the settings in the Daminion Preferences to "write to EXIF/IPTC/XMP - very slow" - not yet tested what means "very slow". The result is a changed RAW file. But DNG is also a RAW format originally created by some manufacturer and not from the Adobe DNG converter E.g. the initial DateTime is: 2019-10-26 10:24:25 the canged by Daminion: 2019-10-26 15:24:25 DxO PhotoLab3 ignores the DateTimeOriginal of the XMP sidecar file and read the Exif from the RAW file: 2019-10-26 10:24:25 Capture One V12 (depending on the setting in the Preferences) reads the DateTimeOriginal from the XMP sidecar file and not from the Exif of the RAW if the XMP sidecar exists Either: 2019-10-26 10:24:25 or 2019-10-26 15:24:25 depends on the settings darktable read the Exif DateTimeOriginal: 2019-10-26 10:24:25 in Photoshop CS6 the XMP DateTimeOriginal from the sidecar file is shown in the RAW tab as: <exif:DateTimeOriginal>2019-10-26T15:24:25</exif:DateTimeOriginal>, <photoshop:DateCreated>2019-10-26T15:24:25+02:00</photoshop:DateCreated> in Bridge CS6 it's shown as: 2019-10-26 15:24:25 and this time stamp is used to rename the file XnViewMP handles the XMP sidecar together with the RAW but ignore the XMP DateTimeOriginal in the sidecar file and read the EXIF DateTimeOriginal from the RAW Use Daminion->Export->CopytoFolder->JPEGOriginal->Rename (%date_%time-%ms.%ext) writes 2019-10-26 15:24:25 to the EXIF DateTimeOriginal of the JPG file regards, Uwe
  11. 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
  12. 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
  13. Last week
  14. Hello, if I adjust the "Creation DateTime" of a CR2 file in the Properties Panel the adjusted value is in the XMP sidecar file - this is ok. But if I call "Read Tags from File" now, I get the old value back because of the way Daminion reads the tags: EXIF:DateTimeOriginal, XMP:EXIF:DateTimeOriginal, IPTC:DateTimeCreated, XMP:Photoshop:DateCreated, Video:CreateDate,File:CreationTime The EXIF:DateTimeOriginal of the CR2 file was not changed by the manual adjustment because of the settings in the Admin Panel->Preferences->Add camera RAW support->Write tags to sidecar .xmp... From my point of view this is a bug. If I use the RAW settings as described, Daminion shoud read the XMP sidecar first if a sidecar XMP file exists. Regards, Uwe
  15. Hi Juha, I understand what you mean and from a IT point of view you are right and I agree. But there is an other side in my mind: I use the milliseconds to get the right sort order of photos taken in the same second (e.g. photos of waves on the sea). If I modify the the Creation DateTime in the Properties Panel I don't want to lose the milliseconds. The reason to adjust the time stamp can e.g. be a wrong time zone setting in my camera that has to be adjusted. I can do it by the shift action or manually. If I rename now the file (YYYYMMDD_HHMMSS_MS) using the adjusted time stamp I get the MS value="000" (because of the database). A read tags from file brings back the MS and I get e.g. the original MS value="340" back to have the previous sort order. Just some thoughts. regards, Uwe
  16. 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
  17. 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
  18. Hi guys, the build with the fix can be downloaded from here, please note that the link is valid for 7 days only. We'll soon publish this version on the web site kind regards daria
  19. I have imported all files from one catalog to a new empty catalog. Then I run DamCompare.py (https://forum.daminion.net/topic/3475-tool-to-check-consistency-of-tags/) and analyzed the reported errors. The most errors were found in the GPS data (altitude). From my 13924 files with GPS differ 11529 files from the catalog! Example: One file with Altitude 431 m (1414.04 ft) in catalog. The file has 256 m (839.9 ft). (Seen in geosetter, windows fileproperties and irfanview) Daminion "Sync->Write tags to file" and "Actions->Write tags to file" bring no change. How can the altitude be written from the catalog to the files?
  20. Hi Nick, seems to be a problem with the PNG format. Convert this PNG to JPG or TIF by PS you get the thumbnails. regards, Uwe
  21. … which will concern about 0.001 % of users. 1. Daminion was unable to create a thumbnail for a really big image (25000x25000 pixels!). Here's the link to that Hubble Deep Field if somebody wants to test it: https://imgsrc.hubblesite.org/hvi/uploads/image_file/image_attachment/31683/STSCI-H-p1917a-f-25500x25500.png Seems excessive, but when you stitch images to make panoramas the result can get that huge. 2. Photoshop duotone images are rendered as plain black and white thumbnails. I'm of course aware that the PS file format is badly documented (see e.g. the amusing rant about that here: https://github.com/gco/xee/blob/master/XeePhotoshopLoader.m#L108 about one third into the code) and that most non-PS software does just that.
  22. Nick

    Is the forum dead?

    No need to apologize, I just found strange that there was so little activity with so many "lurkers". Re. custom tags I came along to have my machine zombified ( 😉 ) but I see you already swatted the bug! Thanks again, N.
  23. Thanks Daria (and to "the guys" who fixed it also, of course).
  24. Sorry, since I never use the menus, I used the wrong term, Egon. You need to Add (or simply press Ctrl+i) the images to the catalog.
  25. Same in my case Uwe. Everything is ok. Do you have just 1 catalog? Do you optimize the NetCatalog? Or any other catalog? If any other, do you have generated previews for any other catalog? Daria
  26. I have exactly the same problem WilfriedB reported on july. (I am able to enable AI Labels, add the Google Vision key and restart the server, but when I select Actions -> Generate AI Labels, nothing happens, not even an error message.) I can see in the database that the table "cloudvision" was updated (one line is inserted) the first time i perform the "Actions -> Generate AI Labels". A line is inserted whith the correct id of the photo. But the second time I perform the action, no line is inserted or updated. I don't know where the Google response should be kept (if there is a table, or a file, to keep the response). On the table "cloudvision", the columns "enddate" and "error" are with null value. And column "value" (maybe the AI tags?) has empty value. At the error logs, I can see some errors like " duplicate key value violates unique constraint "cloudvision_pkey" Severity: ERROR Code: 23505 (this log is at C:\ProgramData\Daminion Software\Daminion Server\Logs\NetCatalog\errors.txt) At other log (C:\ProgramData\Daminion Software\Daminion Server\errors.txt) there are some strange messages like " relation "settings" does not exist Severity: ERROR Code: 42P01 Could anybody help?
  27. Hi guys, good news, we finally could reproduce the issue and the guys have already fixed it. The build will be available this week, I will send you a link asap Daria
  28. Hello Wilfried, how can I import with Daminion? The menu item file-> import-> Daminion Local Catalog (.dmc) is gray (can not be selected)
  1. Load more activity
×
×
  • Create New...