Decide on scaling image

[stalker314314]

Today, we scale image to 1024px (1024px is larger dimension!), with upsampling set to 0. This is mostly value that is set because it worked on my machine😄. Going forward, I wanted to see what is really this value. Higher value means more RAM is needed. Lower value means small faces will not be detected. So, I did some analysis and published it on my blog: https://blog.kokanovic.org/performance-analysis-of-dlibs-cnn-face-detection/

@matiasdelellis - please read when you find time (it is lot of text😄). Basically, some questions for you:

• Are you OK to move content from blog post to wiki here?
• Are you OK to commit python code, output, produced images to repo here (let's say directory "analysis/" in root?)
• Are you OK with hardcoding upsampling to 0 and changing scaling based on RAM of user? I would go with something like this:
  • Read total physical memory on machine
  • If it is less than 2GB and we don't allow usage of Face Recognition app (I really cannot imagine how it can be usable with less than that:/ And even that is bare minimum)
  • Assume that free/available memory is 1/2 of total RAM memory (I would not go into inpecting free -h results (or amount of swap space) and use that in calculations, as it changes over time and we want consistent budget over time (unless user upgrades RAM physically😄)
  • Formula: Scale [megapixels] = RAM[GB] / 1000 (so, 2000GB of RAM will scale to 2MP, 4000GB to 4MP...)

Again, I would not go into inspecting currently free memory, because scaling will be very dependent on current load on machine. Also, I would not go into some self-adaptive logic (for example, if we hit OOM, we try again with lower size...)

Your thoughts?

[matiasdelellis]

Wow.. very interesting.. :smile:

Are you OK to move content from blog post to wiki here?

Yes .. It is very relevant as information to potential users. :wink:

Are you OK to commit python code, output, produced images to repo here (let's say directory "analysis/" in root?)

Sincerely, I would prefer to have a separate repository for it.. but it's okay. It is not very standard, but it is the same case of placing the documentation images in the repository. :sweat_smile:

So, do it.. :wink:

Are you OK with hardcoding upsampling to 0 and changing scaling based on RAM of user?

Seem right.. Maybe it would be configurable, but this logic is correct.. :smiley:

Again, I would not go into inspecting currently free memory, because scaling will be very dependent on current load on machine.

Exactly, although tempting, this can not be dynamic. If it depended on the system load, when taking two very similar photos, may result in different results.. -Well .. According to your tests does not change much, but change -.

Also, I would not go into some self-adaptive logic (for example, if we hit OOM, we try again with lower size...)

Unfortunately we are going to see many OOM reports. We have to make sure that if it is due to system load, it stops properly -Ignoring the fact that indeed the kernel will kill the process-, and in the next execution, it continues correctly.

If we have OOM because the system has little memory per se, it will fail continuously, and we can not do more than document it as best we can.

Well, Cool!. Very interesting..

[stalker314314]

You were right - I will not taint this repo with some random Python code. I created new repo where I put all images and text, and added to wiki here reference to it. I guess that should do it for documenting stuff:) Now to coding part:)

[matiasdelellis]

Great. When the new scaling is implemented, you can add a summary of the consequences of the analysis regarding the project.

Something like: Taking into account the analysis, it was decided to scale the images ... . .etc.