4 TIFFs in cpg0016 source 7 are broken

[timtreis]

Tripped up one of my pipelines, triage via Claude

Finding: batch_68 has 4 corrupted TIFF files on the public S3 bucket (not a transient network issue):

s3://cellpainting-gallery/cpg0016-jump/source_7/images/20210727_Run3/images/CP3-SC1-18/
  CP3-SC1-18_I22_T0001F003L01A03Z01C04.tif   (ER, stack 138)
  CP3-SC1-18_I22_T0001F004L01A01Z01C01.tif   (DNA, stack 139)
  CP3-SC1-18_I22_T0001F004L01A01Z01C02.tif   (Mito, stack 139)
  CP3-SC1-18_I22_T0001F004L01A02Z01C03.tif   (RNA, stack 139)

All 4 files are exactly 2,768,896 bytes and start with \x00\x00\x00\x00 instead of the TIFF magic (II*\x00 or MM\x00*). The S3 GET returns HTTP 200 with the right Content-Length, but the body content is zero-padded — i.e. upstream data corruption in the JUMP CellPainting Gallery for plate CP3-SC1-18, well I22, fields F003 (one channel) and F004 (three channels).

Confirmed via independent curl over HTTPS (different client, different protocol, different code path from boto3):

Bad file 1 (F003 ER, stack 138):  2768896 bytes, all-zero start AND end
Bad file 2 (F004 DNA, stack 139): 2768896 bytes, all-zero start AND end
Both bad files share SHA256 5943e9d0...  ← byte-identical, deterministic zero fill

Good neighbor (F002 DNA, same well): 2768896 bytes, header II*\0 (valid TIFF),
SHA256 38bdc399... ← different, real image data

[ErinWeisbart]

@shntnu It looks like this was previously identified but treated as a JUMP specific problem and handled by updating the load_data.csv jump-cellpainting/datasets#76

Since we have now received another report of these images being problematic, and since I don't think it's reasonable to assume that all workflows of people reading images off the CPG would use load_data.csv, I propose we:

1. Add a new standard metadata file for all datasets in the CPG that notes artifacts that have been deleted and why (created as necessary, but documented in docs)
2. Delete corrupt images from the CPG

Thoughts?

[timtreis]

For context: I noticed because one of my pipelines was iterating over all raw TIFFs and kept failing, digging into that revealed those images. So any user that might not be aware of such lists and direectly goes to the raw data, will probably have the same hickup

[MattsonCam]

@shntnu It looks like this was previously identified but treated as a JUMP specific problem and handled by updating the load_data.csv jump-cellpainting/datasets#76

Since we have now received another report of these images being problematic, and since I don't think it's reasonable to assume that all workflows of people reading images off the CPG would use load_data.csv, I propose we:

1. Add a new standard metadata file for all datasets in the CPG that notes artifacts that have been deleted and why (created as necessary, but documented in docs)

2. Delete corrupt images from the CPG

Thoughts?

Have the load_data_with_illum.csv files also been updated to handle this problem?