unsupported_filter_op: video-filter ops are dim and crop only

unsupported_filter_op means ops[].op in a Sume video-filter request is something other than dim or crop. Other pixel work goes in filtergraph. A related code, unsupported_filter_op_field, fires when a valid op carries an extra key.

This is from the Video filter docs, read 2026-10-01. Topaz's September 2026 update list names workflows such as Sharpen and Denoise; on Sume, a name like that is not an op value.

Which op names are valid?

Exactly two: dim and crop. Anything else, for example sharpen, blur or scale as an op, returns unsupported_filter_op.

What shape does each op take?

Each op takes a fixed set of keys. Adding a key, even a sensible-looking one, returns unsupported_filter_op_field.

Where does other pixel work go?

Into filtergraph, a filters-only ffmpeg graph applied after ops[]. Only allowlisted filter names are accepted, so check the program first; an unknown name fails as invalid_filtergraph. See the filter allowlist post.

curl -X POST https://api.sume.com/v1/video-filter/check \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "video_url": "https://media.sume.com/artifacts/artf_demo/talk.mp4",
    "ops": [{ "op": "sharpen", "amount": 0.5 }]
  }'

Does the check catch both errors?

The check runs the same schema and op whitelist as the encode and returns diagnostics instead of a 400, so the example above is a safe way to see the refusal. It reserves no credits.