$F in file COP stops working after frame 6

[ryew]

Debugging a strange COPnet issue I've never seen before and wondering if anyone has come across this. 

I have a COPnet I'm reading a sequence of EXR images into for processing.  It reads in with a File COP using the filepath with filename and $F.exr as the extension.  Frames 1-6 read without issue, then starting at frame 7 the File COP no longer reads images if $F is replaced manually with 7 or any frame that follows, but frames 1-6 still read in correctly either with $F or manually using the frame number.

The EXRs are valid, were all rendered at the same time, and can all be read through MPlay, the issue only occurs in COPs as described.  I will also note I have been using COPnets for image processing in multiple scenes for months and this is the first time this problem has occurred; I'm using Houdini 19.5.493 on Windows 10

Things I have tried that have not resolved the issue:
- Verified the timeline settings were on Integer frames, i.e. no subframe increments
- Re-creating the COPnet from scratch both in the same scene as well as a completely new scene following a reboot.
- Creating a frame attribute on a null node to reference in the filename; this works as long as I manually set the frame number, but using $F for that attribute once again fails
- Re-rendering the EXRs
- Converting the EXRs to PNGs

At this point I'm stumped.  It doesn't appear to be a corrupt scene, or corrupt images, and I have never had issues with $F use previously, so there must be something I'm missing.

Has anyone come across this or something similiar with $F no longer working for partial ranges?
 

Edited March 23, 2023 by ryew

[Atom]

I can scrub my jpg sequence fine. You're not mentioning your hardware or image sizes. Certain Houdini licenses do have image size limitations. Can you post your troublesome EXR sequence, the first 7 frames..?

Edited March 24, 2023 by Atom

[ryew]

Thanks, Atom.

Unfortunately I can't share the EXRs due to confidentiality requirements of the work.

I am running Houdini Indie, however the images are only 1936 x 408 and I have been running these same type of networks on much, much larger EXRs over hundreds of frames in sequence for months, so I am confident that neither my hardware nor the image resolution is the source of the issue. 

The same issue happens with premultiplied PNG images, even in a new scene containing only a COPnet with the single File COP, even when the images are all re-rendered from scratch after the Houdini temp directory is cleared out and the machine rebooted or powered off/on, so there's something really screwy going on.

At this point I am looking at machine issues.  I received some forced Windows 10 installs yesterday morning that I've rolled back, I've run the "repair" function on the Houdini launcher, now I'm planning to uninstall and re-install Houdini.

Edited March 24, 2023 by ryew

[Atom]

What if it's the actual name of the file. Are you naming the images "0.exr" etc? what if you add a prefix before the number? I was using $F3, perhaps adding some zero padding might get you over the hump. I assume you tried the obvious and directly loaded image 7 into the file node.

[ryew]

Thanks for the suggestion, Atom; I tried that, but no dice.

Yes, the explicit path works.  What's more, if I use the $F notation and middle-click the path parameter resolve it to the explicit full path, then copy *that* text and paste it in a new file node, that also works.  Reverting the frame number back to $F (or $F3 in this case) not only immediately fails to then load the same image, it breaks the file COP which then fails to load anything if an explicit full path is entered.  Needless to say, confidence in the sanity of my install is not very high at this point.

Again, not something I've ever seen running thousands of frames through COPs over the past 9 months so I'll be re-installing Houdini at the end of the workday; I'll let you know if that actually resolves anything, but I suspect I'll be contacting SideFX over the weekend if not.