Menu
▾
▴
solexatools-devel — A list for developers on the SolexaTools project.
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(7) |
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Brian O'C. <boc...@uc...> - 2008-04-14 21:50:39
|
Hi Blaise, We currently don't have a download tar/gzip file available. So please use subversion to check out a copy. You can find instructions on how to do this here: http://sourceforge.net/svn/?group_id=208516 The SolexaLIMS component is one of two that make up the SolexaTools project (the other one being SolexaPipeline). The SolexaLIMS system will let you track samples while the SolexaPipeline will run analysis on your data. It should be ready to go (you can use the war file provided) but the SolexaPipeline will need tweaking for your setup. Hope that helps --Brian O'Connor B....@nc... wrote: > > Dear madam/sir, > > It is with great pleasure i came across SolexaTools on sourceforge. I > personally believe this is an effort worth congratulating. > I wish to set up such laboratory information management system in our > lab in relation of course to our in house solexa machine. > I could not find a link for downloading the tools on sourceforge. > I will be very please if you would refer me to a link for installing this > great tool. > Hoping to hearing from you at your earliest convenience, thank you very > much in advance for your kind consideration. > > Kindly ; > > > > Blaise T.F. Alako, PhD. > Molecular Biology - Bioinformatics Division > Geert Grooteplein 28, route 259 > P.O. Box 9101 > 6500 HB Nijmegen > The Netherlands > Tel: +31 (0)24-3610535 (direct) > mobile +31 (0)623191127 > b....@nc... > > > Het UMC St Radboud staat geregistreerd bij de Kamer van Koophandel in > het handelsregister onder nummer 41055629. > The Radboud University Nijmegen Medical Centre is listed in the > Commercial Register of the Chamber of Commerce under file number 41055629. > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > > > ------------------------------------------------------------------------ > > _______________________________________________ > Nelsonlab-devel mailing list > Nel...@li... > https://lists.sourceforge.net/lists/listinfo/nelsonlab-devel |
|
From: Brian O'C. <boc...@uc...> - 2008-03-20 23:43:10
|
Hi Robert & Nick, Sorry to take so long to get back to you on this. Things have been crazy in lab since your visit. It was really nice meeting with you and I'm glad we got a chance to talk. The SolexaLIMS web app is the best thing to start with since it's fairly self-contained and should be pretty easy to install. In the solexa-lims directory, you'll find a .war file (under dist directory). That's a pre-compiled version of the site. You should be able to deploy it following the directions in the README. This will let you track your samples being run on the solexa machine. The next step is to install the SolexaPipeline component which integrates with the SolexaLIMS to display information about each of the pipeline steps being applied to the solexa datasets. This project is much less mature and still contains some hard-coded assumptions about our setup in the Nelson lab. The lab now has two developers working on this project to clean it up and get it ready for a 1.0 release. I've cc'd them here along with the solexa-tools list where we post information about the project. In the next couple weeks we're planning on doing a 1.0 release that should address the install issues. If you're interested in hosting me I'm happy to come for a site visit to Yale and help you setup this pipeline after we do a release. Just let me know. Also, I wanted to follow up on our conversation about compressing the data. We really haven't had a chance to work on better compression for the images (or processed data). If you're still interested in working on this I would love to help you out and send you the information on what we've tried so far. I think we can get a 1:5 compression of the image data if we use the lzw compression algorithm from ImageMagick to create compressed tiff image files. I just haven't had time to fully troubleshoot this and make sure the Solexa-provided pipeline produces the same results once the tiff files are compressed then decompressed. We also are thinking about converting text based sequence and intensity output from the solexa pipeline into more compact 2bit and NetCDF binary files respectively. That's something we could explore together if you're interested and would make the exchange of large amounts of sequence data much more practical. Hope that helps!! --Brian Robert Bjornson wrote: > Hi Brian, > > I'm finally back at my desk in New Haven, and following up on my > discussion with you about the solexatools stuff. Nick is very > interested in looking at your stuff, both the LIMS and the pipeline. > We poked around the sourceforge site, but didn't see any downloads, > just the source code repository. From my recollection, I thought that > there was a package for the LIMS, but that the pipeline was a bit > harder to install. > > Can you help me point Nick in the most productive direction for > getting a look at both of these systems? If giving him a login to > your copy of the pipeline is easiest, I think that would be fine > (he'll promise to be very careful and only make read access). > > Thanks, > > Rob |
|
From: Ben B. <be...@gm...> - 2008-01-24 18:21:02
|
Thanks Brian. Do you have a rough estimate when the major new revision will be available? For those of you who didn't see, Illumina released a ChIP-seq application, but it's a module for BeadLab so you'll have to run it interactively on windows to take advantage - not really pipeline friendly :( ben. On Jan 15, 2008, at 3:25 PM, Brian O'Connor wrote: > Hi, > > For those of you interested in using SolexaTools I just wanted to > point out that Jordan and I are currently doing a major revision of > the project to make it as generic as possible. You may have > noticed some assumptions and Nelson-lab specific logic in the > SolexaPipeline subproject (the SolexaLIMS is very clean however). > Anyway, if you're interested in using the current project please > use revision 300 when you checkout from subversion e.g.: > > svn -r 300 co https://solexatools.svn.sourceforge.net/svnroot/ > solexatools/trunk solexatools > > This is the most recent version before we started the refactor. > Email the lists if you run into any problems or have ideas about > improvements. We're also especially interested in adding > developers to the project to help make this project more useful for > a wide variety of uses. > > --Brian O'Connor > Nelson Lab - UCLA |
|
From: Brian O'C. <boc...@uc...> - 2008-01-15 23:25:30
|
Hi, For those of you interested in using SolexaTools I just wanted to point out that Jordan and I are currently doing a major revision of the project to make it as generic as possible. You may have noticed some assumptions and Nelson-lab specific logic in the SolexaPipeline subproject (the SolexaLIMS is very clean however). Anyway, if you're interested in using the current project please use revision 300 when you checkout from subversion e.g.: svn -r 300 co https://solexatools.svn.sourceforge.net/svnroot/solexatools/trunk solexatools This is the most recent version before we started the refactor. Email the lists if you run into any problems or have ideas about improvements. We're also especially interested in adding developers to the project to help make this project more useful for a wide variety of uses. --Brian O'Connor Nelson Lab - UCLA |
|
From: Ben B. <be...@gm...> - 2008-01-14 22:40:48
|
hey brian, Did you hear back from Klaus on the LZW/TIF issue? I noticed that when i use imageMagick to convert the Solexa tiff's to either LZW- encoded TIF or PNG, and then I open the images in either Mac Preview or Photoshop, they appear in the inverted color scheme (white spots on a black background). When i do a simple "Invert" operation in photoshop, it looks the same as the original (by eye). The two documents below talk about "photometric tags" in the tiff file, but i haven't figured out yet how to read or manipulate those. They also mention a way to set either polarity=min-is-black or polarity=min-is- white, but these seem to be for bi-level (black/white) images. http://www.imagemagick.org/script/formats.php http://www.imagemagick.org/discourse-server/viewtopic.php?p=18186 ben. |
|
From: Ben B. <be...@gm...> - 2008-01-10 19:07:25
|
Solexa::Pipeline::SolexaRsync has the following line: >> use Solexa::Config::SolexaConfig; but the SolexaConfig package doesn't seem to be in the repository.. ben. |
|
From: Ben B. <be...@gm...> - 2008-01-10 19:00:02
|
Solexa::Pipeline::SolexaRsync has the following line: >> use Solexa::Config::SolexaConfig; but the SolexaConfig package doesn't seem to be in the repository.. ben. |
|
From: Brian O'C. <boc...@uc...> - 2008-01-10 00:12:56
|
Hi Klaus,
I'm trying to add image compression to the SolexaTools project and I'm
running into some problems. I was hoping to add a step that, rather
than compressing with bzip2 which saves 1/3 of the space, it compresses
with LZW. This would reduce the image files to about 1/5 of their
original size. Since the algorithm is lossless, I was expecting to be
able to do a compression round trip and get the same answer from the
pipeline. When I tried this, the sequences generated was substantially
different suggesting the image conversion was actually causing changes.
I'm using ImageMagick to do the conversion, when I look at the image
before and after the round trip I get the following (using the
ImageMagick "identify" command):
Before:
Channel statistics:
Gray:
Min: 3 (0.0117647)
Max: 24 (0.0941176)
Mean: 4.4793 (0.0175659)
Standard deviation: 1.08192 (0.00424284)
Colors: 21
Histogram:
995: ( 771, 771, 771) grey1
711385: ( 1028, 1028, 1028) #040404040404
210559: ( 1285, 1285, 1285) grey2
41109: ( 1542, 1542, 1542) #060606060606
17605: ( 1799, 1799, 1799) #070707070707
9223: ( 2056, 2056, 2056) grey3
5497: ( 2313, 2313, 2313) #090909090909
2335: ( 2827, 2827, 2827) #0B0B0B0B0B0B
3446: ( 2570, 2570, 2570) grey4
1530: ( 3084, 3084, 3084) #0C0C0C0C0C0C
965: ( 3341, 3341, 3341) grey5
595: ( 3598, 3598, 3598) #0E0E0E0E0E0E
341: ( 3855, 3855, 3855) grey6
201: ( 4112, 4112, 4112) #101010101010
95: ( 4369, 4369, 4369) #111111111111
59: ( 4626, 4626, 4626) grey7
29: ( 4883, 4883, 4883) #131313131313
22: ( 5140, 5140, 5140) grey8
10: ( 5397, 5397, 5397) #151515151515
6: ( 5654, 5654, 5654) #161616161616
1: ( 6168, 6168, 6168) #181818181818
Rendering intent: Undefined
After:
Channel statistics:
Gray:
Min: 3 (0.0117647)
Max: 24 (0.0941176)
Mean: 4.4793 (0.0175659)
Standard deviation: 1.08192 (0.00424284)
Colors: 65536
Histogram:
995: ( 771, 771, 771) grey1
711385: ( 1028, 1028, 1028) #040404040404
210559: ( 1285, 1285, 1285) grey2
41109: ( 1542, 1542, 1542) #060606060606
17605: ( 1799, 1799, 1799) #070707070707
9223: ( 2056, 2056, 2056) grey3
5497: ( 2313, 2313, 2313) #090909090909
2335: ( 2827, 2827, 2827) #0B0B0B0B0B0B
3446: ( 2570, 2570, 2570) grey4
1530: ( 3084, 3084, 3084) #0C0C0C0C0C0C
965: ( 3341, 3341, 3341) grey5
595: ( 3598, 3598, 3598) #0E0E0E0E0E0E
341: ( 3855, 3855, 3855) grey6
201: ( 4112, 4112, 4112) #101010101010
95: ( 4369, 4369, 4369) #111111111111
59: ( 4626, 4626, 4626) grey7
29: ( 4883, 4883, 4883) #131313131313
22: ( 5140, 5140, 5140) grey8
10: ( 5397, 5397, 5397) #151515151515
6: ( 5654, 5654, 5654) #161616161616
1: ( 6168, 6168, 6168) #181818181818
The statistics reported by ImageMagick look identical to me so it looks
like the information content is unaffected(?). Do you have any ideas
why this isn't working. Did you use a standard library for tif file
operations? Are you using a custom Tif file format that may be
disrupted by the conversion by ImageMagick? Does the tif library your
using support LZW compressed tif images directly? Is there a reason why
the images aren't compressed using LZW on the instrument machine? Are
16-bit images needed or does 8-bit provide sufficient dynamic range?
Sorry for all the questions. I would really love to get this added in
because it would seriously reduce the size of our raw data (which we're
currently archiving).
Thanks very much for your help!!
--Brian O'Connor
SolexaTools @ the Nelson Lab, University of California, Los Angeles
PS: I can send some sample images and more verbose output if it's helpful.
Maisinger, Klaus wrote:
>Hello Brian
>
>I just had a look at your Sourceforge project "solexatools". If you have
>any feature requests / issues how the Genome Analyzer pipeline can make
>your life easier, please don't hesitate to let me know (I can't
>guarantee we will act on suggestions but we will do our best. :-)) We've
>also got an email address Pip...@il... for
>development/code related questions/feedback (for user questions please
>refer to tec...@il...).
>
>Thanks for your input
>Klaus
>
>
>
|
|
From: Brian O'C. <boc...@uc...> - 2008-01-09 21:31:03
|
Funny that you're asking about this today. Jordan and I have been looking into this. We're having problems working with the image files Solexa provides. It's strange, they're 16-bit files (1000x1000x2 bytes/pixel) but looking at them using ImageMagic it seems like both the higher and lower bytes are identical e.g. it looks like they're essentially 8-bit images. We've been able to compress them using LZW (lossless) and reduce the file size to 1/5 the original size (which is awesome). The problem is running the solexa image file through ImageMagic causes changes in the file (it looks like the dynamic range is rescaled automatically by ImageMagic). When we do a round trip (tif -> lzw compressed tif -> tif), or even just a tif -> tif convertion, we see drastically different answers coming out of the pipeline (even when the dynamic range isn't reajusted!). I'm looking at the pipeline source code today to see if I can figure out what API they're using to read the images. But I'm hoping someone on the list or someone from Solexa can explain what's going on. --Brian Ben Berman wrote: > > what are you guys currently using to compress the images? I know you > mentioned this lossy one that's used for astronomy. If it's lossy, it > would be good to test the effect on the basecalling error when > uncompressed. We are writing a grant, so i want to decide if we're > going to keep the images or not. > > thanks, > ben. |
|
From: louis f. <lou...@gm...> - 2007-12-20 17:59:59
|
*The following solexa jobs have problems: 071211_HWI-EAS172_200gh processing error* *071207_HWI-EAS172_2015A backup error** 071105_HWI-EAS172_14515 processing error 071026_HWI-EAS172_11989reseq process now is not checked 070806_SLXA-EAS20_5722 **process now is not checked* *070604_SLXA-EAS20_5447 validator error* *070427_SLXA-EAS20_5152 **validator error* *070418_SLXA-EAS20_5256 **validator error* *2) validation_solexatmp_070418_SL * (edit<http://genome.ucla.edu/SolexaLIMS/processingSetup.htm?expID=16&procID=402> ) validator_error Validates the run directory by counting files *1) rsync_tempspace_move * (edit<http://genome.ucla.edu/SolexaLIMS/processingSetup.htm?expID=16&procID=401> ) moved Rsync moves files associated with the run. *070405_SLXA-EAS20_0005_FC5065 **validator error* *2) validation_solexatmp_070405_SL * (edit<http://genome.ucla.edu/SolexaLIMS/processingSetup.htm?expID=15&procID=404> ) validator_error Validates the run directory by counting files *1) rsync_tempspace_move * (edit<http://genome.ucla.edu/SolexaLIMS/processingSetup.htm?expID=15&procID=403> ) moved Rsync moves files associated with the run. * 070403_SLXA-EAS20_0001_FC5063** validator error* * Thank you, *Lou Fridkis UCLA Geffen School of Medicine Department of Human Genetics Nelson Lab 695 Charles E Young Drive S. Los Angeles, CA 90095 USA 310-825-7920 |
|
From: louis f. <lou...@gm...> - 2007-11-21 20:02:49
|
The following experiments have not had the "process now" box checked: AAXX On Nov 19, 2007 9:06 AM, louis fridkis <lou...@gm...> wrote: > The following experiments have processing errors: > > 071109_HWI-EAS172_14034 > 071105_HWI-EAS172_14515 > 070713_SLXA-EAS20_5863 > 070629_SLXA-EAS20_5861 > 070604_SLXA-EAS20_5447 > 070427_SLXA-EAS20_5152 > 070418_SLXA-EAS20_5256 > 070405_SLXA-EAS20_0005_FC5065 > 070403_SLXA-EAS20_0001_FC5063 > > The following experiments have not had the "process now" box checked: > > 071030_HWI-EAS172_14517 > 071026_HWI-EAS172_11989reseq > 070806_SLXA-EAS20_5722 > -- > Lou Fridkis > UCLA Geffen School of Medicine > Department of Human Genetics > Nelson Lab > 695 Charles E Young Drive S. > Los Angeles, CA 90095 USA > 310-825-7920 > -- Lou Fridkis UCLA Geffen School of Medicine Department of Human Genetics Nelson Lab 695 Charles E Young Drive S. Los Angeles, CA 90095 USA 310-825-7920 |
|
From: louis f. <lou...@gm...> - 2007-11-19 17:06:34
|
The following experiments have processing errors: 071109_HWI-EAS172_14034 071105_HWI-EAS172_14515 070713_SLXA-EAS20_5863 070629_SLXA-EAS20_5861 070604_SLXA-EAS20_5447 070427_SLXA-EAS20_5152 070418_SLXA-EAS20_5256 070405_SLXA-EAS20_0005_FC5065 070403_SLXA-EAS20_0001_FC5063 The following experiments have not had the "process now" box checked: 071030_HWI-EAS172_14517 071026_HWI-EAS172_11989reseq 070806_SLXA-EAS20_5722 -- Lou Fridkis UCLA Geffen School of Medicine Department of Human Genetics Nelson Lab 695 Charles E Young Drive S. Los Angeles, CA 90095 USA 310-825-7920 |
