Particle System Frame Count Limit/Issue. HF3Pro and HF4Pro

edited July 2016 in Pro Support

As I've been playing around with images from a CT scan with the particle system,  in this thread I discovered it works fine when you only have 89 images, which I did the first time. Second time, I tried with 130 images and it just kept on repeating a single image for the last part.

I investigated and found it caps out at 102 individual images (image 0 is numbered 1 in my sequence, so they're all out by one).  It doesn't give an error and it's a pretty weird number, even 99 I could have sort of expected, but it means I'm stuck with a partial model. I've been using HF3Pro, but just tested in the HF4Pro Demo and it has exactly the same limit/problem there.

Just to confirm it, I colour-coded some images, then incremented the frame number - not even keyframing it over time, just repeating the same frame throughout - and it gets stuck. Note the frame number changes, but the image doesn't in the last two screengrabs; the last image should be pink for frame 103/IMG104.

I presume I'm SOL in getting an update for HF3Pro :( , but there might be others who would want to be able to use more frames (even to do the same thing as I'm doing?) for HF4 Pro, so...could it have more frames? Or an error message?

Oh yes, nearly forgot: The other error is if the images are numbered (as they originally were) IMG1, IMG2,....IMG10, IMG11....IMG100, IMG101, it gets the display order wrong.

I had to rename them to IMG001, IMG002...IMG010, IMG011, etc. for it to order them correctly.

Better tag a few people, just in case. :) @Ady , @JoshDaviesCEO


  • Triem23Triem23 Moderator

    What's your GPU? I've done more than 107 images for this kind of thing. 

  • edited July 2016

    107? That's another oddly specific number. :)

    Could it be VRAM?  Nvidia Geforce GTX 580 and images are 568x568 .JPGs with an average size of 86kb each..

    Do you think resizing them (actually, cropping some black space would be better to preserve detail) would be worth a try?

  • Triem23Triem23 Moderator

    I meant 100. Typo. Yes, I am gguessing it could be a Vram issue. 

  • edited July 2016

    Not sure how to work out how much VRAM is used, so I changed the Project and the Composite properties both to 720p from 1080p, which should have used less VRAM to render stuff and it made no difference.  Which is weird. Right? :(

    So I then also resized the images to 400x400 and it displayed them all. As I don't want to lose the detail, I'll have to crop them all instead - they could be rectangular and lose no detail - but not sure if I have something that will do that automatically.

    Oh, and then I reset the Project and Composite back to 1080p and they continued to work OK, idea what's going on with the VRAM.

    Cheers for the suggestion.

  • @palacono  This makes sense 568x568=322,634  and 400x400 = 160,000  can you get almost twice the amount of images?   If you have lightroom you can crop one and then copy the crop to all the others. 


  • Triem23Triem23 Moderator

    I don't think it's so much Vram for a final render, I think the Vram also holds the slices, and their individual transformations? 

    The whole particle rig is a way to semi-automate a 300+layer composite (you have over 100 slices and three particle sims if I read correctly), but if the active particle texture is held in Vram...

    Now, JPEGs are really compressed. Uncompressed, each 568x568x24 bit image is about 0.92 MB. Once keyed, it has an alpha channel, so 1.22 MB.  If you have 300 of those then you've suddenly got 360 MB of texture! 

    Of course I assume the buffers have to hold decompressed data. I can be wrong. 

    Oh, on an earlier issue yes, Hitfilm expects all files in an image sequence to have the same amount of characters, so, yeah, filenames need to be ">textstring<000.>extension<" to 140,or whatever. 001, 010, 100. Pretty much any nle I have used os the same. 

  • I don't have Lightroom. I was wondering if I can actually crop/resize the Composite shot containing the images in Hitfilm to about 568x380  and export it as a set of .PNGs at a smaller size, then re-import it.

    Or something.... Idle speculation at the moment. :)

  • edited July 2016

    @Triem23 Actually, I couldn't even get it to work with a single particle system, because I started again from scratch to see if some value I'd changed elsewhere by mistake and couldn't remember (the nested levels in the Particle system are so deep, I keep getting lost. So many "General"s ;) ) was causing the issue.

    But no, a single image sequence, single particle system and it capped out at 102 with just a Demult on them. So, either it releases the VRAM after each Particle system has done its thing or...I have no idea...just waffling. :)

  • Aladdin4dAladdin4d Moderator

    @Palacono For lossless batch cropping try JPEGCrops  It uses jpegtran so there's no re-encoding.

    Thinking in text......If you did convert to PNG and wrapped the images to an MOV would it make a difference?


  • @Aladdin4d thanks, I'll try using that for cropping.

    Dunno what difference it makes having images vs having frames in a movie. I'll have a play about and see.

    Ultimately, I want to combine this left right scan with the front back scan for more detail. If that works: then with the top down scan, although aligning them all accurately in the same 3D space will be fun... ;)

    Then I want to see if it's possible to reslice it - as if it was a solid - at arbitrary angles using 3D? No idea if this is possible, though. :D

  • Aladdin4dAladdin4d Moderator

    @Palacono  One difference is for better or worse QuickTime would be doing the decoding which in turn means a different pipeline for at least part of the process. Whether or not that makes any difference for what you're doing is a whole 'nother question.

Sign in to comment

Leave a Comment