Issue with format (padding is missing) and long sequence detection

[Ophtis]

Hello,
First:
I have an issue using the format function from a pyseq sequence, the padding info is missing in pyseq-0.6.0 but working in pyseq-0.5.1.
For exemple:

seq = pyseq.get_sequences(r"D:\tmp\seq")[0]
seq.format('%4l %h%p%t %R')

Gives me in in pyseq v0.5:
3 myshot.%05d.jpg [41429-41431]

But same code gives in new version (0.6.0):
3 myshot.%d.jpg [41429-41431]

The 05 is missing, should be %05d. I've tried with sequences with 4, 5 digits padding, and various formats.

My 2nd issue:
I've a very long sequence with 5 digits and this is not listed as a single sequence but two separated.
Exemple, these frames:

["SHOT.46997.exr", "SHOT.46998.exr", "SHOT.46999.exr", "SHOT_47000.exr", "SHOT_47001.exr", "SHOT_47002.exr", "SHOT_47003.exr"]

Give:
<pyseq.Sequence "SHOT.46997-46999.exr">, <pyseq.Sequence "SHOT.46997-46999.jpg">, <pyseq.Sequence "SHOT_47000-47003.exr">, <pyseq.Sequence "SHOT_47000-47003.jpg">,

Is it normal ? Am I missing something ?

Thank you & best

[rsgalloway]

Hi Sophie,

Thanks for the report. The reason you're seeing the first issue is because the frames don't start with a 0:

$ ls
myshot.41421.jpg  myshot.41423.jpg  myshot.41425.jpg  shot.00002.jpg  shot.00004.jpg
myshot.41422.jpg  myshot.41424.jpg  shot.00001.jpg    shot.00003.jpg  shot.00005.jpg
$ lss
   5 myshot.%d.jpg [41421-41425]
   5 shot.%05d.jpg [1-5]

I believe this was changed in 0.5.3 with PR #63. Besides the change in behavior is this causing problems for you? If so, maybe there's a better way to solve this.

For the second issue, it looks like you've got some frames that are dot separated ("SHOT."), and some that are separated with an underscore ("SHOT_"). It works if they all match, e.g.

>>> frames = ["SHOT.46997.exr", "SHOT.46998.exr", "SHOT.46999.exr", "SHOT.47000.exr", "SHOT.47001.exr", "SHOT.47002.exr", "SHOT.47003.exr"]
>>> get_sequences(frames)
[<pyseq.Sequence "SHOT.46997-47003.exr">]

Hope that helps : )

[Ophtis]

Hi Ryan,

Thank you for your quick reply ! And sorry for the second point, you are right.

For the padding, yes the change of behaviour is causing problems, we rarely have sequences starting at 0 in VFX, it's created from the edit. Besides, starting at a high number allows us to have handles.

Do you think it can be included again ? Pyseq is BTW very nice, we use it a lot.

Thank you and have a great weekend.

[rsgalloway]

It used to work that way, but was changed in #63 to resolve issue #60.

we rarely have sequences starting at 0 in VFX

Sorry, I didn't mean starting at frame 0, I meant padded with 0s, e.g. shot.01001.jpg, which has a %04 pad, but the sequence starts at x1001. I've seen all kinds of sequence numbering conventions (even negative frames), and pyseq should support all of them if possible.

Are your frames always padded? e.g. if you had frame x1001, would your convention be shot.01001.jpg (padded) or just shot.1001.jpg (not padded)? I assume the former, but just want to confirm.

Here is an unpadded sequence (%d) starting at frame x998:

["SHOT.998.exr", "SHOT.999.exr", "SHOT.1000.exr", "SHOT.1001.exr"]

and the same sequence as padded (%04d):

["SHOT.0998.exr", "SHOT.0999.exr", "SHOT.1000.exr", "SHOT.1001.exr"]

pyseq knows the first sequence is unpadded, and the second is padded, but it's hard for pyseq to know if this sequence is padded or not:

["SHOT.46997.exr", "SHOT.46998.exr", "SHOT.46999.exr", "SHOT.47000.exr"]

because there's a) no leading 0s, and b) no frames with only 4 digits in the sequence. Hope that makes sense.

I think the solution here might be to tell pyseq if sequences are always padded or not, instead of it trying to make a best guess. What do you think?

The strict_pad global was supposed to address this, but seems like there's still some work to do there, so I'll file this as a bug and work on a fix.

[Ophtis]

🙏 for the explaination, yes it makes sense.

We can have both, and that's the struggle (both padded and not padded) since the images are coming from extremely various sources (camera, CGI, editing, clients...), even in most cases there are not padded.

But indeed, if strict_pad could allow me to cover most cases like before, it would be perfect. 🙂

[rsgalloway]

Please test this branch:

https://github.com/rsgalloway/pyseq/tree/issue-69

In cases where you want strict pad checking, you will need to enable it. You can do this by setting a pyseq.strict_pad=True or using an environment variable:

$ export PYSEQ_STRICT_PAD=1

In cases where you don't want strict pad checking, this should be disabled: pyseq.strict_pad=False or

$ export PYSEQ_STRICT_PAD=0

[rsgalloway]

Hi @Ophtis just following up to see if you've had a chance to test this yet?

[Ophtis]

Hello!

Sorry for the late reply, I wrote some tests in my side to be sure, but it's working with PYSEQ_STRICT_PAD = 1 🙂

Thank you!

[rsgalloway]

OK thank you for verifying :)

I'll merge this change soon and close this ticket.