About training time cost

[joshua19881228]

It's a great implementation. And I can see that it only costed 12 minute to get 91872/202599. I wonder what your hardware setting is because it took about 1 hour to get 1568/596385 in my own 4 Titan xps. Or is there anything wrong with my experiment settings?

[nashory]

Yes, it should be extremely fast because multi-threaded dataloading is supported in my code (https://github.com/nashory/loader-torch). In addition, in the very early stage, the resolution is only 4x4, tiny images which not cost-expensive at all. However, I guess when the training goes on, and you starts to load high resolution images (e.g. 512x512 or 1024x1024), the training time could slow down. (The speed for 1 iteration could be same, as the batchsize for 1 iteration becomes small.)

Thank you

p.s. Anyway where does that 596385 images come from? CelebA dataset contains 200K images as I know. If you have used 1024x1024 images, I recommend you not to use them for the early training, since it would slow down loading and resizing process. I am using normal 256x256 CelebA dataset for the experiment now.

[nashory]

You can check my hardward setting described in README though :)

[joshua19881228]

@nashory Thanks. It ran much faster after I re-run the run.py. The original images are collected by parsing from the internet and the faces are detected and rotated to 140*140. I planned to use progressive-growing-gan to generate other kind of images. But for now I wanted to verify whether it can generate faces because in my understanding, faces are easier to generate.

It is really a great work of you implementing pggan. I'll also share my progress to you if they are helpful for your implementing.

[nashory]

@joshua19881228 yes, it will be greatly helpful more contributor like you tries to fix bugs by running in different environment. Because training this PGGAN is very time consuming which makes it harder to debug. good luck! :)

[joshua19881228]

I've got a 16*16 result. It seems to be a failure.... One of my sample is like this

[nashory]

yeah, It's pretty much hard to transfer from 8x8 to 16x16. I found LRN(1) un my code is actually harmful (not sure but maybe.) I just removed all LRN and tanh layers. I figure PGGAN is extremely sensitive to network structure, and since the authors made slight changes to the existing layers(e.g. pixelwise norm / minibatch discrimination, generalized dropout etc.), It is hard to reconstruct exactly same structure the paper used. I will post the result if I succeed to generate 16x16 image.

[joshua19881228]

@nashory In the paper, there is a sentence "we represent training and generated images in [-1,1]". I am not sure whether it means that we should re-arrange the pixel value to [-1,1] or you have already done that in the code.

[nashory]

dataloader converts the range into [-1,1,]. That's why I could use Tanh() for the generator :) you can check preprocess.adjust_range function in preprocess.lua file!

2017. 11. 9. 오후 8:42에 "Joshua Li" notifications@github.com님이 작성:

@nashory https://github.com/nashory In the paper, there is a sentence "we represent training and generated images in [-1,1]". I am not sure whether it means that we should re-arrange the pixel value to [-1,1] or you have already done that in the code.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nashory/progressive-growing-torch/issues/13#issuecomment-343130283, or mute the thread https://github.com/notifications/unsubscribe-auth/AQqOQGWN7UrvLqobqmsu0JN-JgNf5vtTks5s0uVAgaJpZM4QUUhO .