Closed ggut closed 8 years ago
Thank you for reporting. This error can be explained by the case when PNG conversion is running in parallel and removing the tif file. I will check if this is the case.
same problem is also with code of create_jpg , if submission does not wait for png conversion (which is a good thing).
Once I had made a version of original create_jpg (I think I have deleted in meantime...) where filename is deconstructed and file extending is saved in a persistent variable, which can be toggled by a error catching. If fileattrib would be used prior to each loading, it would heavily slow down filesystem (and processing) due to repeated listing of all files.
While forcing illcorjpgs to wait for completion of png conversion fixes the problem, and enables progression, and while it is not worse than what we had been running in the lab for the last years, it also is a missed chance to speed up the human waiting time by a few hours.
Alternative suggestion: make the code of illcorjpgs (and jpgs) smarter so that it can cope with situations, where the images have been renamed, after illcorjpgs (or jpgs - where outcome should be blank image in case of renaming) had been started.
Illumination correction does this retry approach. I strongly recommend against such concurrent IO practice. Such architecture leads to strange unpredictable artifacts. Please - no.
Potential problem is that IlcorJPG creation is started before illumcorrections are calculated.