Given the available RAM in GiB, how to calculate the image size (Maximum side length) ?
Regards
No idea yet, I can give you figures that i've come up with playing with this project so far.
output resoultion - RAM usage
~1280x800 - around 24 GB
~1920x1200 - around 50 GB
I have not testet bigger sizes, it seems that it uses 24 GiB per megapixel of output (using cpu backend).
Jakub [email protected] kirjoitti 16.3.2016 kello 15.49:
No idea yet, I can give you figures that i've come up with playing with this project so far.
output resoultion - RAM usage~1280x800 - around 24 GB
~1920x1200 - around 50 GBI have not testet bigger sizes, it seems that it uses 24 GiB per megapixel of output.
I made quick tests on smaller image sizes (CPU only), with the following results. Note that I did not wait through all the iterations, only to see that the increase settled down.
Using VGG19, default images, default layers
image size: resident memory
320 1.7G (peaks at 2.8G during startup)
480 3.3G
640 5.7G
720 7.1G
800 8.8G
960 12G
Testing at 800px, changing style scale to 2: 8.8 => 20G
Testing at 800px, dropping all but one style layer: 8.8G => 7.6G
Testing with VGG16 (yes, sixteen) with FC layers removed,* using the default layers
800 px 7.9G (from 8.8G with VGG19)
Testing with nin-imagenet-conv, 1 content layer and 3 style layers
800 px 1.8G
640 px 1.2G
Don鈥檛 know how these CPU based results correlate with GPU, but from this it appears that with VGG19 running with 2G RAM would fail because of the memory peak during initialization. Running with nin-imagenet should be possible, there seems to be no memory peak but rather a steady increase up to the values given. But nin-imagenet-conv is no direct replacement, it produces different-looking results and requires tweaking the settings.
These results are all using L-BFGS. I found (to my surprise) that the effect of ADAM regarding memory usage was quite small. It seems to me that the smaller networks with L-BFGS work better with lower memory usage than using VGG19 with ADAM.
Hannu
http://liipetti.net/erratic
Most helpful comment
Jakub [email protected] kirjoitti 16.3.2016 kello 15.49:
I made quick tests on smaller image sizes (CPU only), with the following results. Note that I did not wait through all the iterations, only to see that the increase settled down.
Using VGG19, default images, default layers
image size: resident memory
320 1.7G (peaks at 2.8G during startup)
480 3.3G
640 5.7G
720 7.1G
800 8.8G
960 12G
Testing at 800px, changing style scale to 2: 8.8 => 20G
Testing at 800px, dropping all but one style layer: 8.8G => 7.6G
Testing with VGG16 (yes, sixteen) with FC layers removed,* using the default layers
800 px 7.9G (from 8.8G with VGG19)
Testing with nin-imagenet-conv, 1 content layer and 3 style layers
800 px 1.8G
640 px 1.2G
Don鈥檛 know how these CPU based results correlate with GPU, but from this it appears that with VGG19 running with 2G RAM would fail because of the memory peak during initialization. Running with nin-imagenet should be possible, there seems to be no memory peak but rather a steady increase up to the values given. But nin-imagenet-conv is no direct replacement, it produces different-looking results and requires tweaking the settings.
These results are all using L-BFGS. I found (to my surprise) that the effect of ADAM regarding memory usage was quite small. It seems to me that the smaller networks with L-BFGS work better with lower memory usage than using VGG19 with ADAM.
Hannu
http://liipetti.net/erratic