illumina --> limma?
1
0
Entering edit mode
Anand Patel ▴ 60
@anand-patel-1847
Last seen 9.6 years ago
Using both mouse and human Sentrix-6 beadarrays, I've managed to normalize the arrays both with the beadarray package and the BeadExplorer package. However, despite being able to get an exprSet from beadarray and a BeadSummaryList from BeadExplorer, I'm not sure how to go to Limma from there. The exprSet does contain normalized values for all of the arrays, and I can construct a new phenoData, but they're not log-values of expression . . . >Usage: lmFit(object,design=NULL,ndups=1,spacing=1,block=NULL,correlat ion=0.75,w >eights=NULL,method="ls",...) >Arguments: object: object of class 'numeric', 'matrix', 'MAList', 'marrayNorm', 'exprSet' or 'PLMset' >containing log-ratios or log-values of expression for a series of microarrays How best to get them from their current status in an exprSet to Log2 for use in Limma? Looking at this, I suspect it's something easy -- just take the Log base 2 of each value, then run that modified exprSet through, but am not sure how to do that easily in R. Thanks, Anand C. Patel, MD Washington University School of Medicine acpatel at gmail.com
GO limma beadarray BeadExplorer GO limma beadarray BeadExplorer • 1.6k views
ADD COMMENT
0
Entering edit mode
@sean-davis-490
Last seen 3 months ago
United States
On 8/24/06 2:50 PM, "Anand Patel" <acpatel at="" gmail.com=""> wrote: > Using both mouse and human Sentrix-6 beadarrays, I've managed to > normalize the arrays both with the beadarray package and the > BeadExplorer package. However, despite being able to get an exprSet > from beadarray and a BeadSummaryList from BeadExplorer, I'm not sure > how to go to Limma from there. > > The exprSet does contain normalized values for all of the arrays, and > I can construct a new phenoData, but they're not log-values of > expression . . . newExprSet <- oldExprSet #copy old exprSet for safe-keeping exprs(newExprSet) <- log2(exprs(oldExprSet)) #take log of expression values I think that will do it. Sean
ADD COMMENT
0
Entering edit mode
Sean Davis wrote: > > > On 8/24/06 2:50 PM, "Anand Patel" <acpatel at="" gmail.com=""> wrote: > >> Using both mouse and human Sentrix-6 beadarrays, I've managed to >> normalize the arrays both with the beadarray package and the >> BeadExplorer package. However, despite being able to get an exprSet >> from beadarray and a BeadSummaryList from BeadExplorer, I'm not sure >> how to go to Limma from there. >> >> The exprSet does contain normalized values for all of the arrays, and >> I can construct a new phenoData, but they're not log-values of >> expression . . . > > newExprSet <- oldExprSet #copy old exprSet for safe-keeping > exprs(newExprSet) <- log2(exprs(oldExprSet)) #take log of expression > values Maybe it is to mention that for some normalisations, the log-values can get negative (i.e. for expression values lower than 1). To proceed you can convert the negative values to the smallest positive value. So add this line: exprs(newExprSet)[ exprs(newExprSet) < 0 ] = min(exprs(newExprSet)[ exprs(newExprSet) > 0 ]) Good luck, Axel > > I think that will do it. > > Sean > > _______________________________________________ > Bioconductor mailing list > Bioconductor at stat.math.ethz.ch > https://stat.ethz.ch/mailman/listinfo/bioconductor > Search the archives: http://news.gmane.org/gmane.science.biology.informatics.conductor > > -- ******************************************* Dipl. Math. ETH Axel Rasche Max-Planck-Institute for Molecular Genetics Department Lehrach (Vertebrate Genomics) Ihnestrasse 63-73 D-14195 Berlin-Dahlem GERMANY Tel. ++49-30-8413-1289 Fax ++49-30-8413-1128
ADD REPLY
0
Entering edit mode
Hi Axel, > Maybe it is to mention that for some normalisations, the log-values can > get negative (i.e. for expression values lower than 1). To proceed you > can convert the negative values to the smallest positive value. So add > this line: > > exprs(newExprSet)[ exprs(newExprSet) < 0 ] = min(exprs(newExprSet)[ > exprs(newExprSet) > 0 ]) But that is a really bad idea. There has been a lot of research into this, and if you use a decent normalization method you will not have this problem. Data transformation (e.g. log) and the preceding background correction step have to be considered together, and depending on your taste, you can either use a method that 1. biases the background correction in such a manner that the values stay away well above zero, so that you then can safely apply the logarithm, or 2. use an unbiased background correction, but then apply a variance-stabilizing transformation function (glog) that is meaningful even with negative values. There are many parallels between the two approaches, the bottom line results can be quite similar. The 'vsn' package offers software for doing 2. Best wishes Wolfgang
ADD REPLY
0
Entering edit mode
Hi Wolfgang, Thanks for the advice about the logarithm transformation. I think the data in question here is the output from the Illumina software, in which case it will have already been background corrected at the individual bead level and summarised in a single value for each gene. Can the vsn transformation still be safely applied to this data? btw I would recommend using only the non-normalised output from the Illumina software if you plan to analyse on the log2 scale. All of the Illumina normalisation methods use a "background normalisation" step first which seems to create a lot of negative values. Illumina like to analyse all their data on the un-logged scale despite a very obvious relationship between the mean and variance. In fact, they take this relationship into account in their models for differential expression. If anyone is interested, the following paper discusses their methods: A Model of Technical Variation of Microarray Signals - Chudin et al. Journal of Computational Biology, May 2006 Regards, Mark -----Original Message----- From: bioconductor-bounces@stat.math.ethz.ch [mailto:bioconductor-bounces at stat.math.ethz.ch]On Behalf Of Wolfgang Huber Sent: 24 August 2006 22:30 To: rasche at molgen.mpg.de Cc: Bioconductor Subject: Re: [BioC] illumina --> limma? Hi Axel, > Maybe it is to mention that for some normalisations, the log-values can > get negative (i.e. for expression values lower than 1). To proceed you > can convert the negative values to the smallest positive value. So add > this line: > > exprs(newExprSet)[ exprs(newExprSet) < 0 ] = min(exprs(newExprSet)[ > exprs(newExprSet) > 0 ]) But that is a really bad idea. There has been a lot of research into this, and if you use a decent normalization method you will not have this problem. Data transformation (e.g. log) and the preceding background correction step have to be considered together, and depending on your taste, you can either use a method that 1. biases the background correction in such a manner that the values stay away well above zero, so that you then can safely apply the logarithm, or 2. use an unbiased background correction, but then apply a variance-stabilizing transformation function (glog) that is meaningful even with negative values. There are many parallels between the two approaches, the bottom line results can be quite similar. The 'vsn' package offers software for doing 2. Best wishes Wolfgang _______________________________________________ Bioconductor mailing list Bioconductor at stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/bioconductor Search the archives: http://news.gmane.org/gmane.science.biology.informatics.conductor
ADD REPLY
0
Entering edit mode
On 8/24/06 7:38 PM, "Mark Dunning" <md392 at="" cam.ac.uk=""> wrote: > Hi Wolfgang, > > Thanks for the advice about the logarithm transformation. I think the data > in question here is the output from the Illumina software, in which case it > will have already been background corrected at the individual bead level and > summarised in a single value for each gene. Can the vsn transformation still > be safely applied to this data? > > btw I would recommend using only the non-normalised output from the Illumina > software if you plan to analyse on the log2 scale. All of the Illumina > normalisation methods use a "background normalisation" step first which > seems to create a lot of negative values. Illumina like to analyse all their > data on the un-logged scale despite a very obvious relationship between the > mean and variance. In fact, they take this relationship into account in > their models for differential expression. If anyone is interested, the > following paper discusses their methods: Mark, Have you made any headway with Illumina regarding getting data that is closer to "raw" but still useful? We are getting the probe-level data dumped from our (which I think is NOT background-subtracted, but correct me if I am wrong), but these data do not conform to the usual Illumina output (different unique ids for the probes), so I really haven't given much thought to using them, particularly since I can't convince our collaborators to make hacks of their scanner config file to get the dumps for all the data we receive. Sean
ADD REPLY
0
Entering edit mode
On Fri, Aug 25, 2006 at 09:42:36AM -0400, Sean Davis wrote: <sean>Mark, <sean> <sean>Have you made any headway with Illumina regarding getting data that is <sean>closer to "raw" but still useful? We are getting the probe- level data <sean>dumped from our (which I think is NOT background-subtracted, but correct me <sean>if I am wrong), but these data do not conform to the usual Illumina output <sean>(different unique ids for the probes), so I really haven't given much <sean>thought to using them, particularly since I can't convince our collaborators <sean>to make hacks of their scanner config file to get the dumps for all the data <sean>we receive. <sean> I guess we are getting something like that, but afaik the dumps are already somehow corrected (and I get some negative values). The scanner itself may do some background correction when dumping numbers. You may need to use the raw scanned image, but it may not be possible (if not through an agreement with Illumia). I'm just trying to understand what's in this data, so correct me if I'm wrong. Regards, Stefano -- Stefano Calza, PhD Researcher - Biostatistician Sezione di Statistica Medica e Biometria Dipartimento di Scienze Biomediche e Biotecnologie Universit? degli Studi di Brescia - Italy Viale Europa, 11 25123 Brescia email: calza at med.unibs.it Phone: +390303717653 Fax: +390303717488
ADD REPLY
0
Entering edit mode
So just to clarify, here is the situation regarding BeadArray raw data. If you have made the appropriate tweaks to the BeadScan software then you should get a text file that look like this (for each array/strip); Code Grn GrnX GrnY 50008 796 536.5297 3167.486 50008 495 1574.66 12360.35 50008 706 2120.334 14611.3 50008 519 1493.311 17420.35 50008 938 1549.49 11478.03 50008 612 1989.498 4735.532 50008 744 1073.537 15349.49 .......... ********************************************* For instructions on how to make the tweaks in BeadScan go to http://www.damtp.cam.ac.uk/user/npt22 On that page you will find an xml file to replace the existing Settings.xml file within the BeadScan program directory Note that these steps can only be used before scanning new arrays. I don't know of any way to recover the x and y coordinates for arrays that have been previously scanned. ********************************************* As Sean notes, each bead is identified by a Code and not a TargetID as seen in the BeadStudio output. This is annoying, but it is possible to match up the two identifiers using the bead set manifest that Illumina distributes on their cd's when they give the arrays (its a csv file). The Grn column gives the bead intensity that has been calculated using Illumina image processing methods which include a "sharpening" transformation and a local background correction. It is possible for both these steps to produce negative values. The beadarray package is able to use the TIF images and the X and Y coordinates from the text file to calculate bead intensities. It is possible to re-create the steps that Illumina use although we store the local foreground and background for each bead separately so that background correction is optional. We are also looking to implement a method of background estimation using morphological filtering. We have only just seen this new text format for ourselves, so the code to read these files is only available in the latest version of beadarray in the developers section. So in summary, with the Code, X and Y information plus the .tif image, you can re-create the Illumina image analysis yourself to get raw intensities at the probe level using the beadarray package. Currently this takes around 1min for each array (strip) i.e. about 10-15mins for each chip [ 3Ghz machine with 3GB ram]. Hope this helps, Mark On 25 Aug 2006, at 14:55, Stefano Calza wrote: > > > On Fri, Aug 25, 2006 at 09:42:36AM -0400, Sean Davis wrote: > <sean>Mark, > <sean> > <sean>Have you made any headway with Illumina regarding getting > data that is > <sean>closer to "raw" but still useful? We are getting the probe- > level data > <sean>dumped from our (which I think is NOT background-subtracted, > but correct me > <sean>if I am wrong), but these data do not conform to the usual > Illumina output > <sean>(different unique ids for the probes), so I really haven't > given much > <sean>thought to using them, particularly since I can't convince > our collaborators > <sean>to make hacks of their scanner config file to get the dumps > for all the data > <sean>we receive. > <sean> > > > I guess we are getting something like that, but afaik the dumps are > already somehow corrected (and I get some negative values). The > scanner itself may do some background correction when dumping numbers. > You may need to use the raw scanned image, but it may not be > possible (if not through an agreement with Illumia). > > I'm just trying to understand what's in this data, so correct me if > I'm wrong. > > Regards, > Stefano > > -- > Stefano Calza, PhD > Researcher - Biostatistician > Sezione di Statistica Medica e Biometria > Dipartimento di Scienze Biomediche e Biotecnologie > Universit? degli Studi di Brescia - Italy > Viale Europa, 11 25123 Brescia > email: calza at med.unibs.it > Phone: +390303717653 > Fax: +390303717488 > > _______________________________________________ > Bioconductor mailing list > Bioconductor at stat.math.ethz.ch > https://stat.ethz.ch/mailman/listinfo/bioconductor > Search the archives: http://news.gmane.org/ > gmane.science.biology.informatics.conductor >
ADD REPLY
0
Entering edit mode
Thanks Mark for pointing out this. Regards, Stefano On Fri, Aug 25, 2006 at 04:04:47PM +0100, Mark Dunning wrote: <mark>So just to clarify, here is the situation regarding BeadArray raw data. <mark> <mark>If you have made the appropriate tweaks to the BeadScan software then <mark>you should get a text file that look like this (for each array/strip); <mark> <mark>Code Grn GrnX GrnY <mark>50008 796 536.5297 3167.486 <mark>50008 495 1574.66 12360.35 <mark>50008 706 2120.334 14611.3 <mark>50008 519 1493.311 17420.35 <mark>50008 938 1549.49 11478.03 <mark>50008 612 1989.498 4735.532 <mark>50008 744 1073.537 15349.49 <mark>.......... <mark> <mark>********************************************* <mark>For instructions on how to make the tweaks in BeadScan go to <mark> <mark>http://www.damtp.cam.ac.uk/user/npt22 <mark> <mark>On that page you will find an xml file to replace the existing <mark>Settings.xml file within the BeadScan program directory <mark> <mark>Note that these steps can only be used before scanning new arrays. I <mark>don't know of any way to recover the x and y coordinates for arrays <mark>that have been previously scanned. <mark> <mark> ********************************************* <mark> <mark> <mark>As Sean notes, each bead is identified by a Code and not a TargetID <mark>as seen in the BeadStudio output. This is annoying, but it is <mark>possible to match up the two identifiers using the bead set manifest <mark>that Illumina distributes on their cd's when they give the arrays <mark>(its a csv file). <mark> <mark> <mark>The Grn column gives the bead intensity that has been calculated <mark>using Illumina image processing methods which include a "sharpening" <mark>transformation and a local background correction. It is possible for <mark>both these steps to produce negative values. The beadarray package is <mark>able to use the TIF images and the X and Y coordinates from the text <mark>file to calculate bead intensities. It is possible to re-create the <mark>steps that Illumina use although we store the local foreground and <mark>background for each bead separately so that background correction is <mark>optional. We are also looking to implement a method of background <mark>estimation using morphological filtering. <mark> <mark>We have only just seen this new text format for ourselves, so the <mark>code to read these files is only available in the latest version of <mark>beadarray in the developers section. <mark> <mark>So in summary, with the Code, X and Y information plus the .tif <mark>image, you can re-create the Illumina image analysis yourself to get <mark>raw intensities at the probe level using the beadarray package. <mark>Currently this takes around 1min for each array (strip) i.e. about <mark>10-15mins for each chip [ 3Ghz machine with 3GB ram]. <mark> <mark>Hope this helps, <mark> <mark> <mark> <mark>Mark <mark> <mark>On 25 Aug 2006, at 14:55, Stefano Calza wrote: <mark> <mark>> <mark>> <mark>>On Fri, Aug 25, 2006 at 09:42:36AM -0400, Sean Davis wrote: <mark>><sean>Mark, <mark>><sean> <mark>><sean>Have you made any headway with Illumina regarding getting <mark>>data that is <mark>><sean>closer to "raw" but still useful? We are getting the probe- <mark>>level data <mark>><sean>dumped from our (which I think is NOT background- subtracted, <mark>>but correct me <mark>><sean>if I am wrong), but these data do not conform to the usual <mark>>Illumina output <mark>><sean>(different unique ids for the probes), so I really haven't <mark>>given much <mark>><sean>thought to using them, particularly since I can't convince <mark>>our collaborators <mark>><sean>to make hacks of their scanner config file to get the dumps <mark>>for all the data <mark>><sean>we receive. <mark>><sean> <mark>> <mark>> <mark>>I guess we are getting something like that, but afaik the dumps are <mark>>already somehow corrected (and I get some negative values). The <mark>>scanner itself may do some background correction when dumping numbers. <mark>>You may need to use the raw scanned image, but it may not be <mark>>possible (if not through an agreement with Illumia). <mark>> <mark>>I'm just trying to understand what's in this data, so correct me if <mark>>I'm wrong. <mark>> <mark>>Regards, <mark>>Stefano <mark>> <mark>>-- <mark>>Stefano Calza, PhD <mark>>Researcher - Biostatistician <mark>>Sezione di Statistica Medica e Biometria <mark>>Dipartimento di Scienze Biomediche e Biotecnologie <mark>>Universit? degli Studi di Brescia - Italy <mark>>Viale Europa, 11 25123 Brescia <mark>>email: calza at med.unibs.it <mark>>Phone: +390303717653 <mark>>Fax: +390303717488 <mark>> <mark>>_______________________________________________ <mark>>Bioconductor mailing list <mark>>Bioconductor at stat.math.ethz.ch <mark>>https://stat.ethz.ch/mailman/listinfo/bioconductor <mark>>Search the archives: http://news.gmane.org/ <mark>>gmane.science.biology.informatics.conductor <mark>> -- Stefano Calza, PhD Researcher - Biostatistician Sezione di Statistica Medica e Biometria Dipartimento di Scienze Biomediche e Biotecnologie Universit? degli Studi di Brescia - Italy Viale Europa, 11 25123 Brescia email: calza at med.unibs.it Phone: +390303717653 Fax: +390303717488
ADD REPLY

Login before adding your answer.

Traffic: 598 users visited in the last hour
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6