Thanks for your interest in using beadarray. Unfortunately the .locs
are crucial if you want to be able to perform a full bead-level
data from the iScan machine. You've probably noted that for each
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
indicating which image those coordinates correspond to. A lot of the
quality control measures that beadarray provides rely on knowing the
of the beads, comparing them with their neighbours, but this becomes
impossible when the two images are muddled together. You essentially
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
image, and the processSwathData() function uses these to try and split
Illumina's text file into two, one per image. Without the .locs file
don't currently have anyway of separating the text file. The tiff
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
This is pretty rare (losing twenty beads out of a million is about
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
argument, but since writing the processSwathData code I haven't
a chip where the default hasn't been appropriate, so I haven't got
I'm afraid I can't really offer advice on using lumi, but if you want
continue using beadarray and can't get hold of the .locs files, you
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
anything that uses spatial information such as imageplot, BASH and
will either fail completely or worse give some very misleading
I'm sorry that's not more positive, but the bead-level data from the
machine really isn't in a very helpful format!
Let me know if you have any more queries.
On Tue, Dec 6, 2011 at 10:56 AM, Aliaksei Holik <firstname.lastname@example.org>
> 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
> provided RNA and got a CD back containing the data. Judging by the
> of Swath 1 and 2 files, arrays were scanned using iScan system,
> prompts processing with processSwathData. As far as I understand, I
> three types of files for this processing, including *swath*.tiff
> 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
> files contain the line <compressed>false</compressed> I'm not sure
> 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
> (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
> - Image header ChipName_Sample.xml files
> - ChipName.sdf file
> - ChipName_qc.txt file
> - and finally 8 ChipName_Sample_perBeadFile.**txt files of the
> Code Grn GrnX GrnY
> 10008 102 621.3782 13898.54
> 10008 86 1875.903 23202.34
> 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
> seem to be present in beadlevel txt files. I wonder, therefore, if
> a workaround for the lack of locs files. Alternatively, can I import
> straight into a LumiBatch object providing the format of my
> - Providing I go along with using beadarray for data import, how do
> swathOverlap parameter required by processSwathData. I found segment
> and height in sdf file (only because they were conveniently the same
> as in the command manual), but can't find anything remotely similar
> overlap parameter.
> Your help is greatly appreciated.
> Bioconductor mailing list
<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="">
Computational Biology Group
[[alternative HTML version deleted]]