Hi Arno and Richard,

Thanks for pointing out this bug.  I've been over the C code in the calculateBackground function and modified it in beadarray 1.5.16 to (hopefully!) overcome these problems.  The background values are now assigned to an array of variable size depending on 'backgroundSize' (from M[0] up to M[backgroundSize^2-1]).  There's some additional checking for beads close to the edges.  If you notice any further irregularities, do let us know.

Best wishes,

Matt

-----Original Message-----
From: bioconductor-bounces@stat.math.ethz.ch on behalf of Richard Pearson
Sent: Fri 21/09/2007 12:05
To: Arno Velds
Cc: bioconductor@stat.math.ethz.ch
Subject: Re: [BioC] Beadarray negative background values (bug?)
 
For what its worth, I have seen this same problem myself when running 
beadarray on my mac. I didn't get the problem when running on linux.

Regards

Richard.

Arno Velds wrote:
> I'm seeing unexpected behavior using the beadarray package.
>
> When I'm doing the quantification from the TIFF files and the bead level 
> data files I'm seeing that almost half of the background values have a 
> very large negative value.
>
> I traced the problem into the c file (readBeadImages.c) that does the 
> background calculation. The background value is determined by taking the 
> 5 lowest pixel values from a 17x17 square from the centre of the bead. 
> The array containing those pixel values is initialized as M[289] which 
> is ok. However when you sort the array is calls: quicksort(M, 0, 289); 
> The third argument is used directly on the array and since arrays start 
> at index zero we possibly retrieve random memory.
>
> When I changed that call to  quicksort(M, 0, 288) no negative values are 
> calculated, but I think that doesn't solve everything: The R function 
> readIllumina takes an argument backgroundSize which allows you to 
> specify the background area. I set this value to 25 and the code 
> segfaults which makes sense since we fill the M array beyond the 288 limit.
>
> I think this is a bug, but if I misread the code somewhere feel free to 
> flame me :-) I also checked the dev version and saw no changes in the c 
> file so the problem is probably still there.
>
> Regards,
>
> Arno Velds
>
> The Netherlands Cancer Institute
> Amsterdam, The Netherlands


	[[alternative HTML version deleted]]

