FrothyDog40 ,
ClearML tries to conserve storage by limiting the history length for debug images (see sdk.metrics.file_history_size configuration entry), though the history can indeed grow large by setting a large value or using a metric/variant naming scheme to circumvent this limit.I am aware, but I am not sure what did you try to say by this
Does your use case call for accessing a specific iteration for all images or when looking at a specific image?Yes, for some cases I would like to access a specific iteration.
Note that the debug image viewer (when you click a debug image) provides an iteration scroll control which allows quickly moving across the entire available iteration range for that image.I am familiar with it, however some debug images are not reported every iteration, and can be triggered according to some event. In that case I can' access the iteration scroll..

Other then having the option to choose arbitrary iteration, a filter similar to one in the scalars page where you can display a subset of the reported debug images can be useful

FrothyDog40 , is submitting an issue still relevant?

DepressedChimpanzee34 Thanks for clarifying where the current debug images display falls short for your use case - Extending the filtering to liken the behaviour of the scalars sound like a great idea 🙂

The scalars page provides a metric hide/show control - Is this the one you mean? The debug images page also provides a filter by metric - Depending on your naming policy this can easily be used to focus on more sparsely appearing images.well, it does in a sense, but the poor version. while in the scalars you can browse over full names or headers (full_name= "header / description" format) both from a list or by regexp, in the debug images there is only the header filtering and only from a list..
in my use case I can have above 10 debug images types per category.. so by itself the header is not sufficient
Else, an example of the filter you were thinking of would be appreciated.So the example remains the scalars filtering
Regardless, direct iteration access could definitely extend the debug image page usability - Care to open a GitHub issue?I'll do that hopefully beginning of next week

FrothyDog40 , thoughts?

DepressedChimpanzee34 ClearML tries to conserve storage by limiting the history length for debug images (see sdk.metrics.file_history_size https://clear.ml/docs/latest/docs/configs/clearml_conf#sdk-section ), though the history can indeed grow large by setting a large value or using a metric/variant naming scheme to circumvent this limit.

Does your use case call for accessing a specific iteration for all images or when looking at a specific image? Note that the debug image viewer (when you click a debug image) provides an iteration scroll control which allows quickly moving across the entire available iteration range for that image.

FrothyDog40 , done 🙂
https://github.com/allegroai/clearml/issues/474

DepressedChimpanzee34 Always appreciated

DepressedChimpanzee34
a filter similar to one in the scalars page where you can display a subset of the reported debug images can be usefulThe scalars page provides a metric hide/show control - Is this the one you mean? The debug images page also provides a filter by metric - Depending on your naming policy this can easily be used to focus on more sparsely appearing images.
Else, an example of the filter you were thinking of would be appreciated.

Regardless, direct iteration access could definitely extend the debug image page usability - Care to open a GitHub issue?