Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TagLab using 15 GB of memory #168

Open
Cbmcleod opened this issue Nov 15, 2024 · 10 comments
Open

TagLab using 15 GB of memory #168

Cbmcleod opened this issue Nov 15, 2024 · 10 comments

Comments

@Cbmcleod
Copy link

Every time I try to switch maps in a project, or do basically any task aside from tagging, python stops responding and the memory use climbs up to 15 GB. I'm using a new Mac and tracking the activity monitor and the memory climbs up very quickly and python crashes. I am wondering if anyone has had this issue, and if there is any way to fix it?

@Cbmcleod
Copy link
Author

I wanted to also add that we are not doing training models and are just uploading and tagging the pngs/DEMs. if there is any other helpful information I can provide, let me know.

@Jordan-Pierce
Copy link
Contributor

How big are your maps and DEMs (dimensions, and also GBs)?

@Cbmcleod
Copy link
Author

the maps and DEM's are up 32,000 x 16,900 pixels, and up to 1 GB each- some are 500 MB, others are closer to 1 GB. Also, thank you for the quick response.

(I'm not an expert in this area so I wanted to try to troubleshoot as my colleagues are not having this issue. my memory on my computer is 8 GB so that was my original guess but 15 is such a large amount for a program that I wasn't sure if this was normal)

@Jordan-Pierce
Copy link
Contributor

They are big in size, but not in memory.

How many maps do you have in a single projects? Do you have issues when you have each map in it's own project? Does the issue only occur when switching from one map to another? If it's the latter, then it might be that TagLab stores the map information (raster data) in memory each time you view it (without removing it from memory when you go to another map); so as you go from map to map you're filling up your RAM and eventually run into a memory issue.

@Cbmcleod
Copy link
Author

I have had two maps in one project so far, and that has been the most. The issue occurs when switching between the two maps in the same project, but also occurs when I have one map in each project and switch between projects.

@Jordan-Pierce
Copy link
Contributor

What about opening TagLab, opening project one; closing TagLab, opening TagLab, and opening project two?

Obviously not ideal, but helps to diagnose the problem.

Is there any output from the console log you can share?

@Cbmcleod
Copy link
Author

I have tried this also, but it has pretty similar turnaround time, maybe a little faster.

this is all of the messages for taglab , if that is what you are referring to.
Screenshot 2024-11-15 at 9 14 04 AM

@Jordan-Pierce
Copy link
Contributor

I have tried this also, but it has pretty similar turnaround time, maybe a little faster.

this is all of the messages for taglab , if that is what you are referring to. Screenshot 2024-11-15 at 9 14 04 AM

But it doesn't crash when you restart TagLab each time to open a new Project with a single map?

@Cbmcleod
Copy link
Author

it will just stop responding and ill get the beach ball and the memory goes to around 8GB and says not responding, and it gets there after a bit.

@maxcorsini
Copy link
Member

Jordan correctly explains that TagLab continue to allocate memory when images and DEms are loaded.

When you switch between an orthoimage and its DEM both are loaded in RAM. Your DEM is under the maximum resolution handled by TagLab (that is 32000 x 32000) but it should occupy around 4 GB of RAM. Two DEMs of this type, loaded, occupy 8 GB, plus the size of the corresponding orthoimages. if you have 16 GB of RAM the crash may happen.

An efficient solution to this problem is to manage large maps using a multiresolution approach, but this will require a huge amount of work, and it is not planned at the moment. As a workaround, I suggest you to subdivide them in two pieces of 16000 x 16000 (both the DEM and the orthos) and put all these pieces in your project. If you do not use all simultaneously your memory should be sufficient to work. Let me know if this works.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants