The problem seems to arise from a more noisy red part of the spectrum (see weekly_20220718.png as compared to weekly_20220708.png), and the noise seems to be underestimated (see weekly_20220708_zoom.png) , hence it modifies the balance between solutions and produces errors

There was a fix to the variances applied during sky subtraction made as part of PIPE2D-1055 that merged on 2022-07-12. I was fairly sure that fix was an improvement, but I'll take another look.

The attachment pfsObject-00006-00000-0,0-00000000000103dd-002-0x11fcdfd13c364618.jpg shows the pfsObject spectrum of interest from the 2022-07-17 weekly that ran on Tiger. The black line is the flux, while the two dotted red lines are flux +/- sqrt(variance). The divot around 680 nm is a 3-sigma deviation for a single pixel, but that can't be statistically significant as a line detection. I failed to find any problems in the PIPE2D-1055 fixes. I think I need a more detailed description about the problem before I can track it down on the 2D side.

I have put another zoomed view, where there is a huge spike (about 1000 times above mean value) which is as well around 3sigma, and which might an effect on the continuum.

I have also identified a star spectrum where the variance is obviously wrong especially around 10000A : 

yet another example of significant features that are mistaken for lines : 

There are enough pixels in the spectra that 3 and 4 sigma single-pixel spikes will be plentiful. I don't think there's anything we can do about that. That star spectrum looks problematic though.

The problems with the star spectrum are due to overzealous CR masking, which is a known problem. The simulator produces sharper features than the actual instrument does, so fiber traces often get mis-identified as CRs. This is especially bad in the NIR, where there are lots of bright sky lines, and when working with bright targets. Filed PIPE2D-1063 to tune the CR parameters.

Oh, I should point out that most of the pixels in the drop-out region between 1000 and 1020 nm are masked, but that is not apparent from your plots. It would be helpful if masked pixels were readily distinguishable (or not plotted at all) in your plots, if we are going to use them to find problems.

As for the mask, we take them into account, the point is that the valid pixels are related by lines in out plots. That explains these straight lines over large intervals on this plot 

but there are valid pixels with underestimated variance. If this is due to the specific star spectra problem then fine, but indeed we use the masks. More generally, I wonder if this is worth keeping single isolated pixels between large masked intervals, how sure can we be they are really valid ?

It appears those isolated unmasked pixels with huge flux and underestimated variance also occur in galaxy spectra 

and then are mistaken for emission lines. 

Sorry for this basic question, but there are two mask columns (one in HDU2 and the other in HDU8). Which mask is vlebrun using after all discussion in PIPE1D-53? I found that HDU2 was very different between w.2022.28 and w.2022.29 (and after). No, we are just seeing there are almost no mask in blue and red? Anyway, I still don't quite understand the difference between HDU2 and HDU8 masks. 

drp1d_pipe pfsobject reader uses PfsObject class to read fits ( https://github.com/Subaru-PFS/drp_1dpipe/blob/master/drp_1dpipe/io/reader.py) and we use this reader to convert pfs objects files to our format in the weekly run.

OK, thank you. So, you use basically pfsObject.mask which corresponds to HDU2 on the plots above, I guess. Then, I'm not sure if spectra are masked properly or not.