Cannot cast ufunc 'subtract' output from dtype('float64') to dtype('uint32') with casting rule 'same_kind' error in last code block of 4a

[whitneyt1]

Hello,

We are trying to work through 4a with one run of three FOVs of mouse pancreatic islets. We are trying to compensate the FOVS with the commercial matrix. We originally collected Ca and P as well, but removed those channels from our panel and the extracted images as suggested in #249. When trying to run the last code block to compensate our FOVs we get the following error:

our panel:
Panel55_MousePanel-toffy_PandCaRemoved.csv

Thank you!

[ngreenwald]

@alex-l-kong will you look into this at office hours today.

[alex-l-kong]

Will do.On Nov 16, 2022, at 11:18 AM, Noah F. Greenwald ***@***.***> wrote: @alex-l-kong will you look into this at office hours today. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[alex-l-kong]

@whitneyt1 this looks like a casting issue, which we've had pop up on a particular line that copies the data over.

Can you verify the data type of your raw extracted image data? You can do so by running this in a notebook cell:

from ark.utils.io_utils import list_folders
from ark.utils.load_utils import load_imgs_from_tree
raw_data_dir = os.path.join(extracted_imgs_dir, run)
data = load_imgs_from_tree(data_dir=raw_data_dir,
                           fovs=list_folders(raw_data_dir),
                           channels=panel_info['Target'].values,
                           img_sub_folder='')
print(data.dtype)

You should be seeing np.float64.

[ngreenwald]

What changed that is producing this error? We didn't have it before

[alex-l-kong]

@ngreenwald potentially it's because ark-analysis in toffy was recently bumped to to 0.4.4, and with that a change to dtype handling in load_imgs_to_dir also made it in: angelolab/ark-analysis@f3b9c56.

This change should use the default dtype of the test_img being loaded in instead of requiring an explicit dtype argument. Did we test rosetta on np.float64 inputs?

[ngreenwald]

So did we previously cast the uint32 images to floats when loading the images?

[alex-l-kong]

Looked through the history, doesn't look like we ever did in rosetta.

[alex-l-kong]

I think @camisowers and @srivarra also ran into a potentially related error where np.copy changed the underlying dtype, not sure if we ever resolved this issue though.

[sguldberg]

I copied the rosetta.py notebook and changed the line of code to outputs = np.copy(np.float64(raw_inputs)). The compensate_image_data function ran correctly with that line change.

[alex-l-kong]

@sguldberg @whitneyt1 just opened a new PR (#293) to address the issue you were running into.

[alex-l-kong]

#293 has been tested and merged into main.