Conversation
197g
force-pushed
the
sequenced-write
branch
from
fd50879 to
cf967f3
Compare
|
I've been sketching -adjoin writes (i.e. multiple frames into a single file in an animated format or a container, avif, tif, webp, gif) here: main...image-rs:wondermagick:sequenced-adjoin-writes This will need better support in Just fyi. |
Shnatsel
left a comment
Shnatsel
left a comment
There was a problem hiding this comment.
Looks good, just one nit. Sorry about the delay!
|
Looks good, thanks! Just needs the conflicts to be resolved. I can't do it since write access for maintainers is disabled. |
This parses its argument like the output file. Since that parsing depends on the filesystem we rig up a new context type which ensures the whole system can stay flexible. Note that image-magick also contains a few builtin options like input of patterns and built-in images. We'd presumably load these from bundled files in an install which again are part of a context. Finally, context could also provide acceleration capabilities (including SPIR-V code).
2 participants
Due to the filepath processing this was more complex than it seems at first. I think we'd want to eat the complexity of a new
ArgParseCtxtype now rather than later (see commit message). The testing is an integration test.This is stacked on #76 since it only becomes possible with proper sequence support.
I'm refusing the temptation to extend
imagemagickwith this PR but if we'd want to provide use ofExecutionPlanas a library or even do unit testing then a specialLocationthat writes to a pool of images could also be neat. We should also have the capabilities for output intonull:-(which does not write at all) andfd:1as explained in STDIN, STDOUT, and file descriptors.Feel free to review at your own pace if you want to prioritize operations.