Hello,
Movie File Out to Image Sequences does not produce a frame counter with customizable leading zeros
Setting it up manually using a python f-string and str(me.time.frame).zfill(6) or f'video.{me.time.frame:06.0f}.exr' produces an error, that me.fileSuffix is missing.
Rational for considering this a bug: I rarely encounter stable usage of image sequences without leading zeros frame padding. Leading zeros should be the default.
Expected: image sequences have default leading zeros padding in the frame counter, for example video.000001.exr, video.000002.exr, âŚ
Actual: There is no leading zero in the image sequence frame counter, for example video.1.exr, video.2.exr, âŚ
Adding an int slider, something like âN Leading Zerosâ so me.fileSuffix has x total number of digits for each image/frame would be brilliant.
(Of course, would need to factor in user error when N Leading Zeros gets set to something like 4 and then they render over 9,999 frames, but a quick note about it in the wiki should clear it up for most folks. Chances are the only ones changing the parameter will already understand this risk.)
@martinbackhaus Actually you can get both your padding 0 string examples to work (almost) as long as you include the me.fileSuffix in the expression, ie. removing your explicit â.exrâ.
However in this approach me.fileSuffix then introduces a few extra trailing zeros because it expects the N parameter to insert the numbers (which we have identified as doing so inadequately here).
Maybe this helps you in the meantime, as itâs much easier to deal with striping off â.0.0â afterwards than to fix 0-padding in a batch rename.
So I will classify this as both and RFE to get better control over leading zeros and a bug to hide the extra .0.0 introduced which shouldnât be there if Unique Suffix = Off.
it looks to me, that this âNâ paramter is something like a version number. Really often in pipelines, or also in for example disguise media server version management (or Nuke Compositing), there is a _v001, _v002, âŚ, _v999 pattern (that is recognized also during import of new video files, incl. Frame replacements using _frame####). Also, the moment you âarmâ the node with âRecord: Onâ, a file is being written, so with the âNâ parameter, you can increment this version to avoid overwriting files etc.
In addition to this the frame counter with leading zeros should be configurable
The .0.0 after the frame counter is pretty uncommon, itâs seems safer to me to have the frame counter als last number. But yeah, this works as a workaround.
from a pipeline perspective, I would like to have complete freedom with the naming and string formatting⌠but I also somehow understand, that Touchdesigner wants to check proper naming so it works also with seconds, frames, and throws errors⌠(checking the time COMP at timeCOMP Class - Derivative âŚ)
And, this is another topic and RFE: It would be nice to also create new folders, like the Houdini behaviour, if you have slashes in the file parameter. I remember that nothing happens if there is a subdirectory that does not exist, so also no error message and nothing being written out.
I ran into this issue again, rendering a JPG sequence for a 3d animator/visualization artist who uses 3dsmax⌠and an image sequence is the recommended workflow going into this 3d software.
Using benâs workaround above works⌠just adding an extra framecounter and then removing the second framecounter from TouchDesigner with a rename tool⌠But it is error prone and takes longer than actually rendering the frames
Maybe 3dsmax or whatever tool doesnât need leading zero frame padding. But from a film postproduction QA/QC perspective I would never send out files without it.
attached a PowerRename (Windows PowerToys) screenshot with regex to do this⌠after using the above f-string expression {me.time.frame:06.0f}
