The _place_on_screen function in screen.py adds the paths to the untransformed images after placing images on the screen as a custom StimulusSet attribute:
l.72 converted_stimuli.original_paths = copy.deepcopy(stimulus_set.stimulus_paths)
It seems to me that when result_caching's @store pickles and unpickles the StimulusSet, all attributes not defined in _metadata here in brainscore_core are lost.
Thus, the transformed stimulus set is different when it is computed vs when it is loaded from cache.
This is also the case when the StimulusSet is copied or sliced, see this older StackOverflow entry.
I believe this behavior is completely silent right now, because a) nothing actually uses the original paths, b) there is no test that checks whether result_caching returns identical attributes. Therefore, there is really no urgency to address this right now, but I'd still say it is unexpected/unintended behavior.
Steps to reproduce: load a transformed stimulus set from .result_caching/brainscore_vision.benchmark_helpers.screen._place_on_screen and check for original_paths
Possible ways to address this might be to either
- extend
_metadata
- use
converted_stimuli.attrs['original_paths'] (it seems to me that then the attribute will survive pickling, but it is not a proper attribute so any hasattr check will still fail (?))
- or address it over at result_caching by making a custom store decorator for DataFrames/StimulusSets that preserves any attribute
The
_place_on_screenfunction in screen.py adds the paths to the untransformed images after placing images on the screen as a customStimulusSetattribute:l.72
converted_stimuli.original_paths = copy.deepcopy(stimulus_set.stimulus_paths)It seems to me that when
result_caching's@storepickles and unpickles theStimulusSet, all attributes not defined in_metadatahere in brainscore_core are lost.Thus, the transformed stimulus set is different when it is computed vs when it is loaded from cache.
This is also the case when the StimulusSet is copied or sliced, see this older StackOverflow entry.
I believe this behavior is completely silent right now, because a) nothing actually uses the original paths, b) there is no test that checks whether
result_cachingreturns identical attributes. Therefore, there is really no urgency to address this right now, but I'd still say it is unexpected/unintended behavior.Steps to reproduce: load a transformed stimulus set from
.result_caching/brainscore_vision.benchmark_helpers.screen._place_on_screenand check fororiginal_pathsPossible ways to address this might be to either
_metadataconverted_stimuli.attrs['original_paths'](it seems to me that then the attribute will survive pickling, but it is not a proper attribute so anyhasattrcheck will still fail (?))