[simonandrews]

How is the "Per Sequence Quality" calculated ? Is it an average of the quality of each base in the sequence ? Or is it more complicated than that ?

No, that's it. We calculate the mean quality for each sequence and then display the distribution of those means.

[sowmyai]

Thanks.

In that case, I don't understand how my data could fail the Per Base sequence test(miserably at that - the blue line dips sharply after 35 bp - these are 76 bp reads) and pass the "Per Sequence" test. Thanks for your patience.

[simonandrews]

Thanks.

In that case, I don't understand how my data could fail the Per Base sequence test(miserably at that - the blue line dips sharply after 35 bp - these are 76 bp reads) and pass the "Per Sequence" test. Thanks for your patience.

Ah right - if you look in the documentation you'll see that the per-sequence quality check won't actually issue a warning or a fail - it just shows you the results and lets you decide. There are a couple of tests like this (the GC plot I think is another one). If anyone has ideas for an easy metric to decide if these tests should warn or fail I'd be interested to hear.

[sowmyai]

I was not so much concerned about the pass/fail from the software.

When I say "Passed the Per Sequence quality test" I meant that the histogram peaks very steeply at 34. How can most reads have an average quality of 34 while the individual base qualities are very poor ?

[simonandrews]

I was not so much concerned about the pass/fail from the software.

When I say "Passed the Per Sequence quality test" I meant that the histogram peaks very steeply at 34. How can most reads have an average quality of 34 while the individual base qualities are very poor ?

Without seeing your data it's difficult to say exactly, but you should note that in the per-base plots things can look worse than they are. You tend to find that there is a sudden drop from high to low quality rather than a steady decline. This means that even if you see the bottom of the yellow box extending far down the graph then that only represents 25% of your sequences being poor. This could easily average out to a good mean score across a sequence.

[sowmyai]

I have sent you an email with the reports. Thank you for taking the time to explain.

[lparsons]

Clearer icon

... the per-sequence quality check won't actually issue a warning or a fail - it just shows you the results and lets you decide. There are a couple of tests like this (the GC plot I think is another one). ...

One suggestion would be to change the icon for tests that do not issue a warning or a fail to a blue "i" icon for info instead of the green check mark. That would make it obvious to people that there is no check for this test.

Great software, btw. Thanks for solid work.

[Greg]

This is a really awesome program. I really like how easy it is to use and how clearly it summarizes everything.

One thing, I cant seem to copy and paste out overrepresented sequences. This would be very useful as the first thing I want to do it figure out where the reads come from.

[simonandrews]

One suggestion would be to change the icon for tests that do not issue a warning or a fail to a blue "i" icon for info instead of the green check mark. That would make it obvious to people that there is no check for this test.

I'm actually looking at adding in checks for all tests in the next version. It's just a matter of finding the right measures and cutoffs. Suggestions welcome!

[simonandrews]

How can most reads have an average quality of 34 while the individual base qualities are very poor ?

Having looked into this, it's a bug. The per base quality plot was using the lowest observed quality as an offset instead of the offset determined from the analysis of the encoding used.

In effect this means that the scale on the left of the plot was shifted downwards by whatever the difference in these values was. For Illumina fastq files they were off by 2 Phred units, but it could have been more in other formats.

This will be fixed in the next (impending) release.

[Bruins]

Dear Simon,

How would you like to be cited? It is for a report that will (most likely) not be published.

Thanks,
Wil

[simonandrews]

How would you like to be cited? It is for a report that will (most likely) not be published.

There isn't a paper to cite for FastQC as yet, so it's probably best to cite the project website:

http://www.bioinformatics.bbsrc.ac.uk/projects/fastqc

[simonandrews]

FastQC v0.4.2 released

I've just put FastQC v0.4.2 up on our website.

This fixes the per-base quality plot bug which caused the y-axis to show an offset scale. It also adds more strict parsing of FastQ files to spot incorrectly formatted files, and more cleanly distinguish base called and colorspace files.

I've also now added fail / warn checks to all of the QC modules and improved some of the existing checks which would fail for libraries with unusual GC contents. As part of this I've added a modelled distribution into the per-sequence GC plot so you can see how well your observed distribution fits.

Finally, I've changed the scaling on the graphs in the HTML reports so that wider graphs will be generated for libraries with long reads so you don't get squashed graphs.

You can get the new version from:

http://www.bioinformatics.bbsrc.ac.uk/projects/fastqc/

[If you don't see the new version of any page hit shift+refresh to force our cache to update]

[kmcarr]

I've just put FastQC v0.4.2 up on our website.

Simon,

There appears to be a bug introduced in v0.4.2 related to the "Total Sequences" count reported in the Basic Statistics. The new version consistently under reports the number of reads in the file. Previous versions correctly reported the count.

Looking at the documentation I see that there was a planned feature for sampling just a subset of reads in a file and then reporting an estimate of the total number of reads. Could this have something to do with it?

[simonandrews]

There appears to be a bug introduced in v0.4.2 related to the "Total Sequences" count reported in the Basic Statistics. The new version consistently under reports the number of reads in the file. Previous versions correctly reported the count.

You're right - depending on your file the total sequence count may be off by a few percent (either up or down). It looks like this bug has been in place since v0.2 though!

Looking at the documentation I see that there was a planned feature for sampling just a subset of reads in a file and then reporting an estimate of the total number of reads. Could this have something to do with it?

Yes - that was the basic cause. In an early version we had the option to sample only the first x bases and extrapolate from them. We therefore make an estimate of the total number of sequences based on the record size and the filesize as well as taking a proper count. These days the estimate should only be used for calculating the %complete progress, but I was incorrectly using the estimated rather than the real value in the basic stats.

Thanks for spotting this. I'll put out v0.4.3 later today with a fix for this problem.