Added rate information for the Wan22 vae. This is only used for the 5b
model and the only change is a slight reduction in the preview rate.
Fixed being unable to quickly update multiple frontend widget values
with tab.
Fixed an incorrect default modulus for which forced inconvenient
dimensions for the Load Image node.
The audio input was changed to be discarded when outputting to the
gifski format since gifs do not support audio and other non-audio
supporting formats will silently ignore audio when it cannot be embedded.
This fix was mistakenly added outside the appropriate conditional block
and instead discarded all audio. This was not intended
Resolves#521
An extra pass was added to the ffmpeg_frame_generation code to properly
detect and handle alpha when loading vp9 videos. This early commit
allowed for correct detection, but then failed to apply the decoder to
the main pass, so no alpha was output. This has been fixed.
Resolves#516
This functions so long as multiple nodes aren't providing latent
previews at once. I will need to take time to consider if such
functionality would even be desirable.
Does not resolve subgraphs. Graph traversal functions don't appear to be
exposed, so I'll most likely need to re-implement myself, but I need to
take the time to exhaustively verify first.
Prior ffmpeg implementation provided insufficient precision for frame
estimation and was heavier than desired. Regexes are no longer used
Round frame_rate annotation to at most 2 digits
Some nodes "hash" (actually just mtime) input files to determine if
re-execution is needed. A check has been added to not attempt this
hashing if no file exists.
Fix an incorrect bounds check in the newer frontend widget code.
Previously, detailed response codes were used to indicate what went
wrong on a failed server request. However, this produces un catchable
error messages which are undesirable. Instead, these responses now use
204 to indicate that the request was successfully processed, but returned
no content.
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.
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
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
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