Could you please provide instructions to reproduce this?

I used Topcat on the FluxTable extension, plotted all the pixels (in red), then selected all pixels with mask=0 and overplotteed them (in blue)

the file is pfsObject-00010-00001-1,1-009954820000a57e-006-0x6e85dbfdd0e3cf63.fits

from the GE_COS1 dataset (pfsDesignId=0x608f5cd5e916bf12: visit=83244..83249 )

Actually I had no clear expectation on such a bad part of the spectrum, an I'd wait for the issues on the noise evaluation before focusing on this one, it might just be that it will be solved then

On what file? How was the data processed? What version was used? What do you expect the result to be, and how does this differ from that?

https://github.com/Subaru-PFS/drp_doc/blob/master/pipelineUser/help.rst

At least part of the problem is that mask=0 excludes good pixels as well as bad. On this coadd, we've OR-ed the input masks while excluding bad pixels, so CR means that there was a cosmic-ray at that pixel in one of the inputs, but we've excluded it in the process of coadding (but maybe we didn't do a great job with neighbouring pixels). We've also added a mask plane (which, due to a bug, wasn't showing up; and wasn't being calculated very well) called OVERLAP which indicates pixels from one arm that have better coverage by another arm. So you should ignore pixels with (mask & NO_DATA) != 0.

I've fixed a couple of things in the fluxTable, and made the plot with the correct masking, and I think it looks much better.

looks definitely better indeed. Is this new masking ( ignore pixels with (mask & NO_DATA) != 0 ) going to be definite, or just to wait for your fix ?

In general, you should never expect that all mask planes indicate something bad, so each time you use a mask you need to ask what mask planes you care about.

Merged.