Functionality already exists in Upload variant and backing util
function, so the change is negligible.
Also commit to minor version bump. Other concommitant changes also break
forwards compatibility, so it's a chance to roll multiple together even
if this bump doesn't accompany anything big or flashy.
Co-authored-by: Kaur Kuut <strom@nevermore.ee>
A single item list is now mapped as a template string later flattened to a
variable number of arguments. This handles the case of both no and
multiple arguments
Apply required ProRes fixes from xStrom. While the delays were
unfortunate, these changes should handle any future edge cases and
retains support for older workflows using the numbered ProRes profiles
Closes#451
Introduces two new dynamic arguments which do not generate new widgets
- ["string"]: string is evaluated as template string with kwargs for
values. This allows an argument to reference multiple widgets and
allows multiple arguments to reference a widget
- ["kwarg_key", {}]: This allows for verbose translating of a limited
set of values.
- Multiple dicts can be nested and reference different kwargs
Adds an extra_widgets field to video_formats for widgets do nothing
unless referenced by one of the two new argument types.
Pass has_alpha as a kwarg for reference with the new argument types
Older ffmpeg versions don't include the full option for color_range.
Documentation indicates that pc resolves to the same value and has been
swapped to.
Resolves#445
The format fix for gifski was improperly applied to all outputs. It has
now been properly restricted.
When preview data is sent to the fronted, a format field is sent back
to determine how it is displayed. Gifski and ffmpeg-gif formats use
video for the first term since they use the video_formats subsystem, but
this currently results in them being displayed in a <video> tag on the
frontend.
For now, any format using the gifski route has it's format hard coded to
be corrected to gif, but I'm considering a more thorough update in the
future which will use the video_formats subsystem for images as well and
provides a means for formats to them self specify output type.
Gifs were incorrectly being loaded by a video tag when advanced previews
was set to "Input Only" (the default). The logic for when advanced
previews are used as been clarified.
Resolves#435
Parameters that determine the output quality when advanced previews are
displayed have been moved to only be set when the request if for an
advanced preview. These were ignored when the request was made to the
default /view endpoint, but created undesirable clutter
The prior disconnection logic would eagerly disconnect if the type has
changed at all. In addition to providing awful quality of life, this
was also causing issue with workflows that contain an unbatch node being
saved at all.
The code for type cloning has undergone a substantial rewrite to
properly check link validity and to propogate link events
Resolves#432
Several nodes, like Load Video FFmpeg and Load Audio have a widgets that
take a time in seconds.
These are now handled by an updated widget that will display times as
hour:minutes:seconds and allow entry by hour:minutes:seconds
Having dicts that lie about contents has been officially sanctioned as
the supported way of allowing dynamic inputs, but VHS already had
functioning and well tested code for parsing PROMPT directly.
Since there are issues with Video Combine being used inside dynamic
prompts, it is better to swap to the intentionally supported method.
Resolves#424
SetWidgetConfig is usable on widget options despite the type mismatch.
This provides a cleaner solution than a blind
Object.getOwnPropertySymbols call.
PIL output formats were already passed iterators for improved memory
management over pre-collected lists. Adding a progress bar on top of
this is simple QOL.
The image/webp output is now set to always be lossless. This is
potentially owrht exposing in the future, but I assume lossless will be
preferable the overwhelming majority of the time.
Resolves#405
The prior code of parsing width traces all the way back to f63a0f78
I no longer recall the purpose of the slice, but parsing element
information to determine sizing is inherently flawed. An element width
will not exist until a preview has loaded. Instead, the element size is
back calculated from the node size.
The prior fix to respect rendering threshold had a number of mistakes.
Foremost, a typo in naming prevented it from applying at all. Path
widgets perform rendering separately and need an independent fix. The
comparison has additionally been changed to greater than or equals. This
is most noticeable when low_quality_zoom_threshold is set to 1.0
See #412
About a year and a half ago, ComfyUI changed it's input validation to
allow for specifying which inputs should be validated, but removing the
undesired inputs would cause errors for users who had not updated
ComfyUI to recieve this update. As a result, input validation emthods
were modified to accept an additional kwargs input to allow
compatibility with both the new and old versions. Around the time
execution inversion landed, this was again changed so that a kwargs
input could be used for validation with dynamic inputs. From this point,
the kwargs argument also served to prevent input validation.
Supporting extremely old (>1 year) ComfyUI versions is not currently a
major priority, so these kwargs inputs can be removed to restore input
validation
Resolves#413
Supporting formats on Meta Batches brings back an ugly problem of
expecting users to do math. Restricting selections on the Meta Batch
node would be an onerous amount of work, but as a simple solution, the
closest valid frame is suggested when an error occurs
ComfyUI has added native latent factors for wan, so the ad hoc and
particularly unhelpful factors I made can be pruned.
Fix a missed scoping when checking that meta batch is compatible with a
selected load format. Special thanks to tonirv68.
This is still a bit clunkier than I would like and will likely see
future updates.
Resolves#409
Core has staged a more robust implementation for parsing video metadata.
Once this been rolled out, it should be used instead of the `good
enough` implementation used by VHS.
Austin Mroz