pelkmanslab / iBRAIN_BRUTUS

A version of canonical iBRAIN (2015) deployed on BRUTUS cluster
0 stars 0 forks source link

Create_Jpgs codes (Normal and LIB folder related) do not work with MD images. #34

Open Mat-ABM opened 8 years ago

Mat-ABM commented 8 years ago

Easy to trigger, just submit a bunch of Tiff from the MD. This error is systematic, you can't miss it. Obvious reason: regular expression code is not extracting the proper info from MD file names. It is an urgent issue. Thx!

RHoltackers commented 8 years ago

I don't know if it is any help,

But i've found an easy renaming program called BRU (bulk rename utility) with which you can cut off  the latter part of the MD files.

R

Institute of Molecular Life Sciences Prof. Pelkmans' group University of Zurich, Irchel Campus Winterthurerstrasse 190 Building/Room: Y55-K-72 CH-8057 Zurich Switzerland

phone: +41 44 63 53 172

-----Mathieu Fréchin notifications@github.com schrieb: ----- An: pelkmanslab/iBRAIN_BRUTUS iBRAIN_BRUTUS@noreply.github.com Von: Mathieu Fréchin notifications@github.com Datum: 11.12.2015 11:18 Betreff: [iBRAIN_BRUTUS] Create_Jpgs codes (Normal and LIB folder related) do not work with MD images. (#34)

Easy to trigger, just submit a bunch of Tiff from the MD. This error is systematic, you can't miss it. Obvious reason: regular expression code is not extracting the proper info from MD file names. It is an urgent issue. Thx! — Reply to this email directly or view it on GitHub.

ewiger commented 8 years ago

@Mat-ABM Thanks for reporting this issue.

@RHoltackers BRU program is for sure of general interest, but the problem that Mathieu has described relates to the basic code of iBRAIN and has to be fixed.

ewiger commented 8 years ago

After reproducing the problem - I see the resulted JPGs are completely messed up. Wrong assignment/placement of sites. I will next check parsing of names and compare to older code.

ewiger commented 8 years ago

The same order of images is working for CV7K and breaking for MD naming.

I have checked that the following dependency are working correct

create jpgs
 * -> check_image_postion
 * -> check_image_channel
 * -> get_image_snake
 * -> filterimagedata

Unfortunately did not solved it yet after spending 6 hours on this problem. Will have to continue working on it already in January and switch to other high priority issues for now.

In general, code requires a major rewrite - this task can be solved much simpler by avoiding so many nested loops and confusing index mapping returned by get_image_snake (different as per microscope). E.g. adopting a single naming scheme for images with extracted meta-data as it has already been done in tissuemaps seems to be a necessary critical simplification to produce a single well-tested piece of code.

@tstoeger please take a look at the problem when you are back from holidays - maybe you will be fast to find the cause.

tstoeger commented 8 years ago

@Mat-ABM @ewiger Do you have a path to a folder where the problem can be seen (We have been migrating our data and I'd probably have to spend quite some time finding an MD tiff folder and images acquired on MD) ?

I am happy to attempt to fix the problem if it does not take (much) longer than 30-60min. Maybe I have once somewhere seen a related problem (restoring/updating? regular expressions?).

ewiger commented 8 years ago
ethz-share4/Data/Users/Yauhen/MDbugs/MDbyMat/ILLCORJPG

Problem is visible after opening any output JPG.

@tstoeger thanks for looking into it :+1:

tstoeger commented 8 years ago

While I might miss the problem, I strongly believe that the images of the example dataset have been processed correct.

While the jpgs look somehow funny, this is almost certainly from not imaging some regions between sites. Probably a chosen software setting of the MD.

Alternatively the movement of the samples on MD has changed in an unexpected manner (perhaps during some update? / requiring an update of image_snake) - though I do not think that this is the likely explanation, see below.

Reasons: x Jpgs show images at exactly the correct position (given the site information in their filenames, which thus appears correctly regexp'ed) x huge blobs (MDbyMat_E06_RGB1 ), whose borders should extend beyond a single site, are restricted to a single site (even when they have correct position in composite jpgs). This is quite unusual and indicates that the region next to blob has not been imaged. x Looking at regions without cells, it appears that the relative orientation of sites is correct, but that a small region between sites has not been imaged (perhaps clearest on the multiple gaps within colonies in MDbyMat_F05_RGB2 )

ewiger commented 8 years ago

@tstoeger thanks a lot for your time and help. I will get to the bottom of this and repeat imaging if necessary. Please enjoy the holidays.

tstoeger commented 8 years ago

@ggut should have some recent acquisitions from MD. Possibly looking at his jpgs, and asking @Mat-ABM and @ggut for the name of the scanning protocol that they used, would immediately narrow down if a) there is a general MD setting b) there was an acquisition/protocol specific MD setting .

Opening @Mat-ABM 's protocol in MD software and clicking through registers should also soon show, whether an offset between sites was selected.