The temp image is used only if the exit code is 0.
Yes, that sounds correct. If I use the pngrewrite.exe by iteself as a tool, the 0 and 1 exit codes do seem to affect the usage of the temp image. I can't actually prove it, but it sure looks that way. I can tell, for instance, when an optimizer changes the temp image, but RIOT outputs its own because the optimizer set an exit code of 1. Or when the temp image is changed and is equal to the output image with an exit code of 0. However, I can't tell what happens when an optimizer doesn't change the temp image and sets an exit code of 0 or 1, because obviously the temp image is exactly the output, which is ambiguous. But, I'm not debating your statement; I believe it.
Since RIOT does check whether the temp image is changed, I had thought at one time that maybe this check also determined which image to output, but according to you, it does not. In any case, relying on simply the exit code seems good enough.
For me, all my tools are set up as a script manager program that represents an optimizer or multiple ones inside a script, which means it is guaranteed that the exit code will be 0 (other command interpreters do potentially set exit codes of 1), even if the linked optimizer should set a 1 or something else. So at times, pngrewrite may not overwrite the temp file due to the color depth, but the temp file will still get used anyway as the output, because RIOT examines only the script manager's exit code of 0. This is of no consequence.
Now, here is what happened with my script - Because I was using a script manager program that RIOT waits for to exit, I needed to make sure the master script would not end premature to the optimizer or other slave batch files finishing. Which is why I included a command that would delay ending the master script until cmd.exe closed. Of course the script is fast, so that wait command would likely be executed faster than cmd.exe might start, foiling it altogether, which is why I also included a timer to wait before watching for cmd.exe to close, giving it time to start. This was all very good, because it ran parallel to the slave script, most likely would never extend the run-time, and meant that it would enable closing the script immediately when finished, further eliminating excess run-time.
Now for the problem. When I created the timer setting, I didn't take into account cold startup delays of cmd.exe, which often occurs to programs not already prefetched or cached. In fact, there are many other reasons a program will not startup in a predictable time. Consequently, the timer ran out, the master script ended, the slave script continued, and RIOT thought the tool was done, so it used the temp file as is, which brought about a -100% reporting, due to the fact that the temp file was unchanged.
Then, the next file would be quickly queued in the batch, but remember, the slave script was still running usually, so a file-in-use error would occur and then an access violation on top of that. Stopping the batch process and instantly re-running it, worked, because now cmd.exe was primed to go and the timer was now suitable to run the whole thing smoothly. Additionally, this explains why it was random, because it depended on when I used the tool during the day.
As soon as you bump up the timer to compensate for these cold startups, then the issue disappears, but of course this adjustment means that the operation might waste a few milliseconds in some instances utilizing fast optimizers. Plus, it will never work if a huge bottleneck is encountered at some point, like if the virtual memory swap file caused a disk access delay. Good reason to upgrade memory, invest in a SSD, or use a RAM disk.
But wait, there is more! As I was unraveling this, I was testing batch files as tools, but they weren't working in RIOT's Batch mode, just in the main window. I remember reporting about a similar bug before, so maybe it never was fully fixed. I could tell this time because images were giving me the -100% values as well, indicating no changes to the temp image. Therefore, I tried a tiny test batch file that would result in a 0 exit code:
ECHO success>>D:\log.txt
Running this tool in Batch mode never created the log file, so RIOT is not running batch files properly.
