IM5 => IM3 transfer nonsense

[Richard]

For implementing such an export feature I would schedule about 12-16 work hours.

Hi Mario,

When I am testing IMatch 5 I do so by doing real work that needs to be done for my image files. That makes my testing real world for me. The sad thing is that I must make those same changes in IMatch 3.6 if I want to keep them safe. One alternative is to risk working on my real files in IMatch 5 and hope that I will not have to lose all my efforts due to a bug. Another is if the XML file is considered safe I can save the file as an export before each new beta version. This would allow me to work entirely in IMatch 5 and accomplish both beta testing and cleaning up my files. A third possibility would be to export the XML and import it into IMatch 3 if it was possible.

By asking about the third option in Ben's thread, it seems I confused him so I have created this thread. I considered the two questions  as having the same goal. Safeguarding the effort that testers expend in IMatch 5. The advantage of what Ben calls nonsense is that my time can be used to my benefit today. I do not have to wait until IMatch 5 is released to the public and for all my relatives to upgrade. That later part may take a very long time because some only use IMatch for family photos and do not need the power of IMatch 5. Nor would some want to invest the time to learn how to use IMatch 5.

I know that I would like to be able to see changes to files, that I have made in IMatch 5, safely stored in IMatch 3.6 for my real images. It would show me that things were being accomplished as I would like. If I am the only beta tester still working in IMatch 3.6 in addition to IMatch 5, then I would not expect you to invest a few days to fulfill my request. However, if a hundred beta testers would like to see their testing efforts safely stored in their 3.6 database, that would change the value of my request.

If the average beta tester spend just 5 hours per week testing IMatch 5 and there are >400 testers, that is over 2,000 hours weekly. A  very considerable amount of time. Just today I spent over 5 hours writing XML to my main files, copying those files to my test folder, and allowing IMatch 5 to ingest the changed files. That last step alone took an hour and 15 minutes. While that is computer time and not my time, it still takes some of my time. Now my the files from my IMatch 4.6 database are back in sync but that will not last long. Plus it means that any work I did in IMatch 5 since the beta began was lost.

I wanted to expand on my thoughts about IM5 => IM3 transfer. I am not psychic so I can not claim that it is nonsense for everyone and would like to hear from other testers.

[Mario]

Hi, Richard

I understood your intention clear enough when you wrote about it in the other thread. And the two topics are related so I did not see a problem answering both. The missing thread view in the new forum software makes it harder to handle two strands of discussion in the same thread, except we use heavy quoting which makes things less readable.

So far I don't recall many requests with similar intents. I guess most testers just work with the Beta as a separate entity and do not really consider migrating data back to version 3. The XML-based export/import of categories in IMatch 5 works and is stable for many builds. You can use that when I have to ship a new beta which requires a rebuild of the database (which I will do only if there is an inevitable breaking change in the database).

Looking at the bug and feature list, plus Mantis, plus my own to-do list makes me concentrate real hard on bugs first.

1:15 seems rather slow. How many files did you import?

[Richard]

1:15 seems rather slow. How many files did you import?

3,849

[Mario]

Mhm. Do you have by chance kept the log file?
Do you create cache files on import as well, or only on demand?
Which file format did you process?

[Richard]

I did not keep the log file because IMatch 5 is always slow.
I do create cache files on import but in this case I did not import any new images. I simply allowed IMatch to respond to the fact that all the image files had new modified dates.
The images are in JPEG or TIFF formats

[Mario]

because IMatch 5 is always slow.

Also during operations like showing folder contents, making category assignments etc. ? Or mainly only during the ingest / import phase?

image files had new modified dates.

That causes a complete reload of the images. Metadata import, file data import, re-creation of cache files and the like. The full program. Generating cache files usually doubles or triples the ingest/update time. That's why I asked.

If you perform that again, please send me the log file so I can see how long things take. Using ExifTool causes a performance hit, but the benefits are much bigger. The rest (ingesting, file data extraction, check-sum generation etc.) is as fast as in IMatch 3, at least in my tests.

I don't recall your machine spec, but maybe you can make a test with a value of 1/2 the number of the processors in your computer under Edit > Preferences > Application: Process Control. If you have only one or two CPUs, set both to 1. This is still an open issue, finding the optimal number of background threads for processing which balances the available CPU power and the throughput of the hard disks without causing to many waits (aka slow performance).