Examples: query, "exact match", wildcard*, wild?ard, wild*rd
Fuzzy search: cake~ (finds cakes, bake)
Term boost: "red velvet"^4, chocolate^2
Field grouping: tags:(+work -"fun-stuff")
Escaping: Escape characters +-&|!(){}[]^"~*?:\ with \, e.g. \+
Range search: properties.timestamp:[1587729413488 TO *] (inclusive), properties.title:{A TO Z}(excluding A and Z)
Combinations: chocolate AND vanilla, chocolate OR vanilla, (chocolate OR vanilla) NOT "vanilla pudding"
Field search: properties.title:"The Title" AND text
Answered
Ux Question\Request: Is There A Planned Interface Feature To Enable Convenient Debug Images Scrolling ? Or Maybe There Is A Different Way To Do It? When It Gets To 1000'S It Gets Very Frustrating, It Literally Requires 100'S Of Clicks To View A Debug Imag

UX question\request:
Is there a planned interface feature to enable convenient debug images scrolling ? Or maybe there is a different way to do it?
When it gets to 1000's it gets very frustrating, it literally requires 100's of clicks to view a debug image of interest..
An option to manually choose the iteration number can be very useful

  
  
Posted 2 years ago
Votes Newest

Answers 9


FrothyDog40 , is submitting an issue still relevant?

  
  
Posted 2 years ago

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.

  
  
Posted 2 years ago

DepressedChimpanzee34 Always appreciated

  
  
Posted 2 years ago

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

  
  
Posted 2 years ago

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

  
  
Posted 2 years ago

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?

  
  
Posted 2 years ago

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 šŸ™‚

  
  
Posted 2 years ago

FrothyDog40 , thoughts?

  
  
Posted 2 years ago
616 Views
9 Answers
2 years ago
one year ago
Tags