I get wierd outputs!

[mdorkhah]

Using some available pre-trained models, I get wierd output images like these:

s

What could be the reason?.

[PDillis]

Are they the same config that you set? e.g., if you set --cfg=stylegan3-r, did you resume from the checkpoint with the same config? Otherwise, these look like the outputs of a network that's starting from scratch.

[mdorkhah]

Are they the same config that you set? e.g., if you set --cfg=stylegan3-r, did you resume from the checkpoint with the same config? Otherwise, these look like the outputs of a network that's starting from scratch.

I'm just using pretrained model "stylegan3-r-afhqv2-512x512" and try to generate images using the following command:

python gen_images.py --outdir=out --trunc=1 --seeds=2 --network=https://api.ngc.nvidia.com/v2/models/nvidia/research/stylegan3/versions/1/files/stylegan3-r-afhqv2-512x512.pkl

By the way, I don't see any config option in gen_images.py

[PDillis]

Ah I see, I misread, thought you were training your own model (as the outputs are exceedingly similar to the outputs of a new network).

Could you try forcing fp32? #59 also had similar outputs to you, so this might be useful.

[mdorkhah]

Ah I see, I misread, thought you were training your own model (as the outputs are exceedingly similar to the outputs of a new network).

Could you try forcing fp32? #59 also had similar outputs to you, so this might be useful.

Thanks Diego, I don't know why but it works with forcing FP32!

[Tollanador]

I wonder if it is related to this:

F.1 Generator architecture
Normalization (configs D–R) We have observed that eliminating the output skip connections in StyleGAN2 [34] results in uncontrolled drift of signal magnitudes over the generator layers. This does not necessarily lead to lower-quality results, but it generally increases the amount of random variation between training runs and may occasionally lead to numerical issues with mixed-precision training.

Although that quote is in the context of training, what we are seeing here may be an outcome of these 'numerical issues'.

From the readme:

The generator consists of two submodules, G.mapping and G.synthesis, that can be executed separately. They also support various additional options:

w = G.mapping(z, c, truncation_psi=0.5, truncation_cutoff=8)
img = G.synthesis(w, noise_mode='const', force_fp32=True)

gen_images.py has this in the code:

img = G(z, label, truncation_psi=truncation_psi, noise_mode=noise_mode)
img = (img.permute(0, 2, 3, 1) * 127.5 + 128).clamp(0, 255).to(torch.uint8)
PIL.Image.fromarray(img[0].cpu().numpy(), 'RGB').save(f'{outdir}/seed{seed:04d}.png')

My python skills are a pretty janky, however it seems to me that the gen_images.py script doesn't specify to force_fp32 for the synthesis, whilst loading the model is defaulted to not using fp16:

def load_network_pkl(f, force_fp16=False):

My guess is that when using the gen_images.py script, G.synthesis fails to be informed to set 'force_fp32=True', I'm unsure what (or if) the default is for force_fp32 for G.synthesis, I'm guessing it is 'False'?
Is this a problem specific to the R-type config?

[bisraelsen]

I was able to address the problem in gen_images.py by adding force_fp32=True to line 135:

img = G(z, label, truncation_psi=truncation_psi, noise_mode=noise_mode, force_fp32=True)

[porterlin]

I was able to address the problem in gen_images.py by adding force_fp32=True to line 135:

img = G(z, label, truncation_psi=truncation_psi, noise_mode=noise_mode, force_fp32=True)

Thank you very much. It works for me!!