Dear members, This is my first attempt to analyse a microarray and I would greatly appreciate some help. The data was generated using MOUSEREF-8_V2 BeadChip by a third party. I provided RNA and got a CD back containing the data. Judging by the presence of Swath 1 and 2 files, arrays were scanned using iScan system, which prompts processing with processSwathData. As far as I understand, I need three types of files for this processing, including *swath*.tiff files, locs files and beadlevel.txt file. That's where the problem begins. 1) All images I received are in jpeg format. And even though Image header files contain the line <compressed>false</compressed> I'm not sure I'd be able to import the data into beadarray using these images. 2) I seem to miss .locs files. The files I've got in each chip's directory (I had 2 chips hybridised in total) are: - various *.jpeg files including files containing swath in the name - ChipName_Sample_Grn.idat files - Effective.cfg file - Several Metrics.txt file (it appears there were several rounds of scanning) - Image header ChipName_Sample.xml files - ChipName.sdf file - ChipName_qc.txt file - and finally 8 ChipName_Sample_perBeadFile.txt files of the following format: Code Grn GrnX GrnY 10008 102 621.3782 13898.54 10008 86 1875.903 23202.34 Etc... My questions are: - Do I need to wait for tiff files or can I use available jpegs? - As far as I understand, locs files contain bead coordinates, but these seem to be present in beadlevel txt files. I wonder, therefore, if there's a workaround for the lack of locs files. Alternatively, can I import data straight into a LumiBatch object providing the format of my beadlevel txt file? - Providing I go along with using beadarray for data import, how do I find swathOverlap parameter required by processSwathData. I found segment width and height in sdf file (only because they were conveniently the same size as in the command manual), but can't find anything remotely similar to the overlap parameter. Your help is greatly appreciated. Aliaksei.

Hi Aliaksei, Thanks for your interest in using beadarray. Unfortunately the .locs files are crucial if you want to be able to perform a full bead-level analysis on data from the iScan machine. You've probably noted that for each array section you get two images, but only one text file. As you said the bead-coordinates are in the text file, but unfortunately there's no flag indicating which image those coordinates correspond to. A lot of the quality control measures that beadarray provides rely on knowing the layout of the beads, comparing them with their neighbours, but this becomes impossible when the two images are muddled together. You essentially get two halves of the array partially overlaid on each other and spotting spatial trends doesn't work. The .locs files do only contain coordinates, but crucially you get one per image, and the processSwathData() function uses these to try and split Illumina's text file into two, one per image. Without the .locs file we don't currently have anyway of separating the text file. The tiff images are not crucial, but are far more useful than the jpegs. In processSwathData they are used to identify the image a bead should be assigned to if it can't be done using the coordinates in the locs file alone, but if you don't have the tiff a problematic bead is simply removed. This is pretty rare (losing twenty beads out of a million is about the worst I've seen), so not having the tiffs isn't too detrimental. If you manage to get hold of the .locs file, then I would use the default swathOverlap value. I should really automate it and remove the argument, but since writing the processSwathData code I haven't encountered a chip where the default hasn't been appropriate, so I haven't got round to it. I'm afraid I can't really offer advice on using lumi, but if you want to continue using beadarray and can't get hold of the .locs files, you can set the argument forceIScan = TRUE to readIllumina() and it will read the bead-level text files you have. You can then still get some of the benefits such as outlier removal on the log scale, but bear in mind that anything that uses spatial information such as imageplot, BASH and HULK will either fail completely or worse give some very misleading results. I'm sorry that's not more positive, but the bead-level data from the iScan machine really isn't in a very helpful format! Let me know if you have any more queries. Mike Smith On Tue, Dec 6, 2011 at 10:56 AM, Aliaksei Holik <salvador@bio.bsu.by> wrote: > Dear members, > > This is my first attempt to analyse a microarray and I would greatly > appreciate some help. > > The data was generated using MOUSEREF-8_V2 BeadChip by a third party. I > provided RNA and got a CD back containing the data. Judging by the presence > of Swath 1 and 2 files, arrays were scanned using iScan system, which > prompts processing with processSwathData. As far as I understand, I need > three types of files for this processing, including *swath*.tiff files, > locs files and beadlevel.txt file. That's where the problem begins. > > 1) All images I received are in jpeg format. And even though Image header > files contain the line <compressed>false</compressed> I'm not sure I'd be > able to import the data into beadarray using these images. > > 2) I seem to miss .locs files. The files I've got in each chip's directory > (I had 2 chips hybridised in total) are: > - various *.jpeg files including files containing swath in the name > - ChipName_Sample_Grn.idat files > - Effective.cfg file > - Several Metrics.txt file (it appears there were several rounds of > scanning) > - Image header ChipName_Sample.xml files > - ChipName.sdf file > - ChipName_qc.txt file > - and finally 8 ChipName_Sample_perBeadFile.**txt files of the following > format: > Code Grn GrnX GrnY > 10008 102 621.3782 13898.54 > 10008 86 1875.903 23202.34 > Etc... > > My questions are: > - Do I need to wait for tiff files or can I use available jpegs? > - As far as I understand, locs files contain bead coordinates, but these > seem to be present in beadlevel txt files. I wonder, therefore, if there's > a workaround for the lack of locs files. Alternatively, can I import data > straight into a LumiBatch object providing the format of my beadlevel txt > file? > - Providing I go along with using beadarray for data import, how do I find > swathOverlap parameter required by processSwathData. I found segment width > and height in sdf file (only because they were conveniently the same size > as in the command manual), but can't find anything remotely similar to the > overlap parameter. > > Your help is greatly appreciated. > > Aliaksei. > > ______________________________**_________________ > Bioconductor mailing list > Bioconductor@r-project.org > https://stat.ethz.ch/mailman/**listinfo/bioconductor<https: stat.et="" hz.ch="" mailman="" listinfo="" bioconductor=""> > Search the archives: http://news.gmane.org/gmane.** > science.biology.informatics.**conductor<http: news.gmane.org="" gmane.="" science.biology.informatics.conductor=""> > -- PhD Student Computational Biology Group Cambridge University [[alternative HTML version deleted]]