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.ethz.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]]

