Answers.Body: <p>I found the problem:</p>
  <p>After converting the images to tensors I was using <strong>torch.reshape</strong> to try swapping the order of &lt;width, height, channels&gt; to &lt;channels, width, height&gt;. However, this didn't work like I had intended and the data was being mutilated.</p>
  <p>The proper function is <strong>torch.permute</strong>, which has solved the issue.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-09-08T09:46:52.390Z
Answers.LastActivityDate: 2024-09-08T09:46:52.390Z
Answers.UserDisplayName: Mandias
Body: <p>I've implemented a CycleGAN in Pytorch for style transfer between images. However, I've noticed during training that a distinct &quot;window pane&quot; pattern emerges, regardless of how I tweak different hyperparameters like CNN filter sizes and strides.</p>
  <p>Example images (left: early in training, middle: later in training, right: original image):</p>
  <p><a href="https://i.sstatic.net/VaT44Wth.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/VaT44Wth.png" alt="Early" /></a><a href="https://i.sstatic.net/Jf3oGQN2.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Jf3oGQN2.png" alt="Later" /></a><a href="https://i.sstatic.net/VwPUFJth.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/VwPUFJth.png" alt="Reference" /></a></p>
  <p>This pattern is proving difficult to completely remove, so I'm wondering if something about the way the model is set-up might be causing it. Is there something obvious that I can check?</p>
  <p>Some additional context:</p>
  <p>The encoder portion takes size &lt;3, 256, 256&gt; images and converts them to &lt;512, 1, 1&gt; via Conv2D, BatchNorm2D, ReflectionPad2d, and LeakyRelu layers. The encoded images are then passed through a resnet-style transformation portion (same types of layers), then through a decoder which mirrors the layout of the encoder. Using other encoded sizes, such as &lt;64, 13, 13&gt; makes no difference. Varying the number of layers and their sizes makes no difference either.</p>
  <p>Please let me know if more information is required.</p>
  
Tags: <pytorch><generative-adversarial-networks>
Title: "Window Pane" pattern when training CycleGAN
UserDisplayName: Mandias
ThreadText: # "Window Pane" pattern when training CycleGAN
  
  (Asked by: username_0 on 2024-09-05)
  
  I've implemented a CycleGAN in Pytorch for style transfer between images. However, I've noticed during training that a distinct "window pane" pattern emerges, regardless of how I tweak different hyperparameters like CNN filter sizes and strides.
  
  Example images (left: early in training, middle: later in training, right: original image):
  
  [![Early](https://i.sstatic.net/VaT44Wth.png)](https://i.sstatic.net/VaT44Wth.png)[![Later](https://i.sstatic.net/Jf3oGQN2.png)](https://i.sstatic.net/Jf3oGQN2.png)[![Reference](https://i.sstatic.net/VwPUFJth.png)](https://i.sstatic.net/VwPUFJth.png)
  
  This pattern is proving difficult to completely remove, so I'm wondering if something about the way the model is set-up might be causing it. Is there something obvious that I can check?
  
  Some additional context:
  
  The encoder portion takes size <3, 256, 256> images and converts them to <512, 1, 1> via Conv2D, BatchNorm2D, ReflectionPad2d, and LeakyRelu layers. The encoded images are then passed through a resnet-style transformation portion (same types of layers), then through a decoder which mirrors the layout of the encoder. Using other encoded sizes, such as <64, 13, 13> makes no difference. Varying the number of layers and their sizes makes no difference either.
  
  Please let me know if more information is required.
  
  **Tags:** pytorch, generative-adversarial-networks
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2024-09-08. Score: 1 | Accepted answer
  
  I found the problem:
  
  After converting the images to tensors I was using **torch.reshape** to try swapping the order of <width, height, channels> to <channels, width, height>. However, this didn't work like I had intended and the data was being mutilated.
  
  The proper function is **torch.permute**, which has solved the issue.
  
  
  ---
  
  