Error message about 'The number of USER objects has reached a maximum of 9800'
Hi guys,
The goal of batch processing is to open more than 600 images for analysis, and each image will be closed immediately after the analysis is completed. The image processing steps will open each image one by one and than to make two or three mask image to do image processing and counting.
Unfortunately, our program will pop up an error message about 'The number of USER objects has reached a maximum of 9800, please close some workspaces and try again.' when it reaches more than 300 images.
We try to write another simple Apps program that only executes the process of open image and close image. The same message will pop up after reaching about 1200 images.
If we close this error message, IP-10 will pop up another macro execution error message about '(&H80131502) Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index'.
I guess this is a macro bug caused by the workspace object being closed because the object does not exist.
I'm not sure if the problem is a limit on the number of workspace objects or the memory on IP-10 has not been effectively reuse.
Please help me to solve this annoying problem, thanks!
We developed an Apps program for image batch analysis on IP-10 version 10.0.4.
The goal of batch processing is to open more than 600 images for analysis, and each image will be closed immediately after the analysis is completed. The image processing steps will open each image one by one and than to make two or three mask image to do image processing and counting.
Unfortunately, our program will pop up an error message about 'The number of USER objects has reached a maximum of 9800, please close some workspaces and try again.' when it reaches more than 300 images.
We try to write another simple Apps program that only executes the process of open image and close image. The same message will pop up after reaching about 1200 images.
If we close this error message, IP-10 will pop up another macro execution error message about '(&H80131502) Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index'.
I guess this is a macro bug caused by the workspace object being closed because the object does not exist.
I'm not sure if the problem is a limit on the number of workspace objects or the memory on IP-10 has not been effectively reuse.
Please help me to solve this annoying problem, thanks!
0
Answers
It looks like some objects are not released in the macro loop. Can you please send us the "Loop on" macro and a couple of test images, so we can check the problem?
Thanks,
Yuri
No, this is not related to "Individual Object display limit", it's rather related to accumulation of "User objects" and not releasing them. Every Windows program may have only 10000 objects, so the code should take care of closing unnecessary windows and releasing unused objects.
Yuri
We wrote a testing Apps that only performs simple OPEN image and CLOSE image jobs, also monitor the changes of the USER objects field in the TASK MANAGER.
When Apps executed nearly 1290 images, the number of USER Objects in the TASK MANAGER was also close to 9,800. For sure, as long as the number of USER Objects exceeds 9,800, IP-10 will immediately pop up the error message. It's interesting that we have tried different image formats with the same result.
In addition, we used the BATCH PROCESSING tool to do the same test. The number of USER Objects will be controlled within a normal range will not continue to increase. So we are sure that the BATCH PROCESSING tool will continuously releasing useless USER Objects.
May I know if there is any way to release USER Objects manually?
Happy New Year and Thank you in advance!
Br,
Jims
If you confirmed that the number of user objects do not increase during batch processing, then something special is in your app. User objects are created by UI elements, so you may check if your app dialog is not accumulating them. Try switching off any app dialog updates during batch processing and see if it makes any difference.
Yuri
Please refer to the attached project file.
We were tested commands 'DocumentCommands.Open' and 'MCimage.open'.
And just only using a 'for ... next' loop to open image. It will increase user objects number continue until finished the loop.
After that, i clicked any workspace function in IP-10. The user objects number was immediately reduced.
[ Ready for open image loop ]
[ Looping 20 times ]
[Finished loop]
[Just open new image from workspace button]
Best Regards,
Wesan
Thank you for providing a test macro. I could also see that the number of user objects increases in the loop, though all objects are released properly when I run GarbageCollect macro after that.
We will investigate the issue further, and for now I can suggest a solution that would avoid User Objects accumulation and speed up the processing: you can open images as "invisible", which is much faster and doesn't create UI elements with associated events. All commands will handle invisible images the same way as visible, just pass the right img object.
Here is how a modified version of OpenMcImageTest macro may look like:
And that's how you can modify ApplyImage macro to work with invisible images:
Yuri
...this problem is related to the number of GDI objects. You can increase that number that is by default 10000 in the windows registry, then it will appear less often. You can switch the number to max 65,536. Search registry for GDIProcessHandleQuota.
In WS7 it gave the right error message, from then on it just crashes (up to killing your explorer and need of full restart).
If Yuri's suggestion would work? - I guess so because if not producing image handles, then those handles are also not counted up. However, I did not yet find solutions for all functions to run with .visible = False.
Best
Daniel
The problem is related to the the quota on GDI objects and USER Objects per process. Yes, the default is 10000 and you can adjust it in the registry, but Image-Pro checks it itself and the default limit is 9800 (though it could also be adjusted in the settings, but not exceed the registry value).
We are working on fixing the issue and it should be included into the next patch, but for now, you can use my recommendations as workarounds. Working on invisible images will prevent USER and GDI objects accumulation in loop macros and also significantly speed up processing. If you cannot find a way to run some functions on invisible images, please send me the code (Click here to upload files) and I will check it.
Regards,
Yuri
Actually the problem was resolved for v9.3 and Windows 10, but now appearing again with IPP v10 and Windows 10 (and likely also 11).
Will you work on this again, please?
It is very tedious since in the meanwhile we are not allowed to change registry anymore and every time have to poke the IT administration to do this (on 5 computers). It's unfortunately not stable with updates (WS updates again reset the GDI object limit to the senseless 10.000...
Best wishes,
Dan
Can you please share your macro and several test images, which could reproduce the problem? I want to check if the macro can be modified to avoid accumulation of User objects (e.g. working with invisible images, or clean ups).
If you can share it, please upload the IPX file and test images here: Click here to upload files.
Yuri
My macro is huge and it will not be easy to give you that (needs quote some environment as well). Also it does not make a difference.
The problem is linked to IPP10 with WS10, appeared with WS7 and IPP 9.2, was resolved with WS10 and IPP9.3 and now appeared again with IPP10. All with the same code (and I use garbage collect asf), so code-independent. This just has to do with image handles in WS and obviously you had a solution already in 9.3. It just did not go through to IPP10. We need this high number of handles due to our very high throughput image analyses...
Best
Dan
The leak of user and GDI objects was fixed in latest updates, so it doesn't exist in IP 10.0.11 for image and set windows, but the issue is to release all unused objects within the macro loop (calling GarbageCollect within the loop will not work), so you may use shorter loops and call Garbage Collect manually, after executing the loop, or use Timer events.
I've attached a test macro that checks user and GDI object leaks opening and closing images, run every macro several times to see if they detect any leaks.
If no leaks are detected by test macros, try to modify macros adding your code, that could reproduce the leaks, so we can investigate the problem.
Yuri