can convert return how long it will take to process?

[kernelsandirs]

Is there a way to run my convert command with a flag that can tell me how long it will take to process without actually running the command, so I can return that value to the user before running the real command?

IE...

/usr/local/bin/convert -returnproctime -density 100 -resample 72x72 uglybanner6x4.tif -colorspace RGB ub.jpg
(-returnproctime is fake of course but hoping there is something like it, please tell me there is )

output like : 27s

then if I run
/usr/local/bin/convert -density 100 -resample 72x72 uglybanner6x4.tif -colorspace RGB ub.jpg

it runs about 27s

[magick]

There is no such option. It would not be difficult to return a estimated workload factor which you could then convert to an estimated runtime but it would be relatively costly to compute. Perhaps 10% of the actual runtime and it would be far from accurate since runtimes depend on current loads on your computer, disk activity, cache coherency, and the phase of the moon.

[kernelsandirs]

yeah the moon phase is where I thought I'd really run into an issue
Thanks I figured the best I can do is identify and based on all the depth info number of colors and all the other parameters that make convert differ in proc time would be my only route, Guess I am just going to really generalize and just get the basic depth info run some tests to see how the machine handles all kinds of sizes depths etc and then start using something like "This could take 2-4 minutes to process" etc..

Thanks

[anthony]

That type of educated guess is the best you can hope for.

But any program would need to adjust its guessing stratagy basied on previous performance measures. that is the program should be timing its IM runs and adjusting the 'guess' basied on THIS machines performance.

I have done simular things with long loops. I run a fast pre-loop to find out how many 'things' it needs to do (number and sizes or files to process for example), then run the main loop so it repeats the count and makes a guess for when it will finish.

I often can get a fairly accurate measure of 'time spent, amount completed, time remaining, and overall process time (amount this varies gives an indication of how accurate it is) as a counting status report to the user.

Of course the programs I add this to generally run from a few hours to a few days. One such program I left run for more than a month, but I knew it would take that long, and left it running on the side.

however If I get a report of 10 to 20 years!!! Then I know it is running too slowly


ASIDE: this wasn't with image processing but text file comparisions of roughly half a million files! Since that time such runs generally take less than a day, due to better processing methods and faster computers. But the technique is the same for any type of 'guess' system.

[kernelsandirs]

doing more thinking I think with some of these using some of these suggestions, I may be able to also create a database that tracks the time jobs take based on all of the files attributes and the machine's current load and over time I may be able to produce results that are closer and closer to the actual process time, by tracking real work as it happens and comparing them by generating a useful matrix(of course the database tracking would only track the pertinent info like color depth machine load and time it took to process and what ever else is important at completion. then each day I can have it auto fine-tune a usable matrix that is much lighter to read from as far as getting a quick result for possible process time.