Closed tstoeger closed 9 years ago
Did this had any effect?
The count in CheckImageSet
I am not aware of an effect - which does not mean that there is none.
Personally I often look at the number in CheckImageSet to see if indeed the full dataset has been robomoved/copied from the microscope. If one runs multiple plates, this number immediately tells, if moving was fine (contrasting counting files by file-browser, CheckImageSet is immediately present and one does not have to wait).
Perhaps more importantly, the number now is wrong, whereas it was not in the past. This could hint that something changed during early steps of processing (before CellProfiler).
Also it is worrying and misleading to a user, if iBrain reports a different number of images than is present (e.g.: if running a critical experiment, I would use external functions to manually check that all anticipated microscopic images, which should be present, are indeed present) -> Ultimately one would likely start to ignore this number -> Thus one would loose / ignore the first test, which would indicate if the microscopic image set is likely correct (and usually immediately identifies incompletely robomoved/copied datasets) (see above).
the number is not interpreted by iBRAIN, only the presence of the file.
Indeed this information is useful for the user. We can put it to the list of missing features for new iBRAIN_UZH version. It can be shown by website, since we abandon flag files. I will email the respective task force.
see share7\ ... Data\Users\RNAFish\TestIBrainConversionFromCv7k
Check image set counts 103 objects instead of 96 (see CheckImageSet_103.complete within \TIFF) .
The original dataset from Cv7k is present in \Orig (please keep the \Orig).
Hypothesis: image set wrongly counts the 7 *.tif from Cv7k that are (correctly) moved to /METADATA/CV7K (the shader and camera correction files that are always automatically generated by CV7K)