The sequence progress counter tracks number of subs taken vs total requested subs. Sometimes we throw subs away, but the counter cannot be decremented to reflect that, so you have to increase the total number of subs. It gets confusing how much progress you have actually made. I met one person who uses a binary editor to modify the sequence file to decrement the number! If that’s not an indication that there’s a need for a ui change, I don’t know what is.
In the past I requested more sophisticated sequence progress tracking, like decrementing the counter for subs marked BAD, i.e., SGP would look at the number of subs in the output folder not starting with “BAD” to determine value of the progress counter. But I would gladly settle for the ability to manually bump the counter up and down.
Yes, that would be nice. I actually keep a spreadsheet on each object that tells me how much time I have on the object in each filter. I then reset the sequence each time after deleting the bad frames.
This has been a fairly popular request. At least the beginnings of it will be present in 2.4.2:
So… if you mark an image bad and you decide you want to alter the number of captured frames such that it reflects only “good” frames, you can now do this. This will make it easier to determine when you are “done”. This can be accessed by double clicking the fraction text or the progress bar.
I would like to find a way to work this into the actual “bad frame” system so that when you mark an image as bad it can automatically decrement the captured frames counter for you. SGPro’s current implementation makes this a little difficult since the bad image system can be used on any item in the recent past. SGPro does not keep all these images in memory (too much RAM) so it would require implementation of a meta data system in order to correlate the current image (the one you are actually viewing) with a target and event number (there are complications here dealing with target name changes, target ordering changes and event ordering changes (essentially making sure that we don’t accidentally modify the wrong event… like the event where this frame used to be).
