>Тут вспоминается Костин трюк со спутников для поиска заборов толщиной в один пиксель и то, как народ борется за +-1 пиксель на границах в задаче про машинки
Прочитав pix2pix arxiv.org/pdf/1611.07004.pdf стала понятна мотивация использования GAN, т.е. пишут что просто L1 loss дает более размытую картинку чем L1+cGAN. (но видимо cGAN даёт при этом кучу глитчей)
Возможно это правда не очень красиво и ворнинг возникает
# /usr/local/lib/python3.6/dist-packages/keras/engine/training.py:490: UserWarning: Discrepancy between trainable weights and collected trainable weights, did you set `model.trainable` without calling `model.compile` after ?
# 'Discrepancy between trainable weights and collected trainable'
iphysic
Еще пара вопросов чего не хватает в keras чтобы реализвать GAN?
Не хватает variable_scrope чтоб потом взять подмножество переменных для генератора и дискриминатора? generator_vars = tf.get_collection(tf.GraphKeys.TRAINABLE_VARIABLES, "generator")
discrim_vars = tf.get_collection(tf.GraphKeys.TRAINABLE_VARIABLES, "discrim")
Почему мы в при обучении делаем по несколько шагов (`k_step`) для генератора и дискриминатора?
iphysic
Почему лэйблы добавляются и в discriminator? и зачем нам вообще нужен discriminator если мы можем генерировать изображение по лэйблу просто генератором?
Что то CropNumbers/NumBase какие то битые 0.bmp-625.bmp и с датой норм, а остальные почти все битые или у меня только так? Распаковывал на Ubuntu 14.04. И почему .bmp, а не .png?
1. Так на вход подаются картинки одинакового размера? т.е. LSTM тут не обязателен?
2. Если вы делали end-to-end то почему же сразу не сделали картинка->текст?
Похоже я всё понял, кроме одного, зачем кропать dst feature map если не было добивки нулями src feature map? т.е. использовалась 'valid' свертка(т.е. уже произошло уменьшение spartial размера), или пиксели на краю 'плохие' сами по себе, а не потому, что мы добивали src feature map нулями перед сверткой в режиме 'same'?
Насколько я понял на вход сети подаётся, допустим RGB, картинка (W+k) x (H+k), а маска(ground truth) имеет размер W x H, k пикселей по краям берутся из оригинального большого изображения.
В вашем случае k = 16, т.к. 16 сверток 3x3, каждая из которых съедает по пикселю, как было описано выше.
В итоге это избавляет от артефактов на краях тайла.
В U-net судя по пейперу идёт кроп перед каждым пулингом и не описано по какому принципу.
Т.е. размер паддинга по краям тайла и размер перехлеста вы установили экспериментально?
Я изначально имел ввиду что то такое:
Т.е. в зависимости от архитектуры сети можно добить тайл по краям так, чтобы в конце мы получили feature map у которого мы отбросим рамку в 1 пиксель вокруг, а внутреннюю часть возмём, таким образом я предполагаю можно избавится от дефектов.
Судя по пейперу U-net используется unpadded convolutions, но не написано по какому принципу они кропают центральную часть feature map'а. Тут вот судя по коду на это вообще забили.
Имеется ввиду что когда делается свертка, то на аутпут блобе делается padding типа same добивая нулями и от этого всё портится?
Т.е. надо взять тайл изначально большего размера, добив его по краям k/2 pixels от большого изображения, на краях(там где кончается большое изображение) используем отражение.
Так вот насколько я понимаю k это как раз и есть receptive field пикселя с выходного feature map (который имеет меньший spartial размер чем входной тайл) или как высчитать k?
Потом от конечной feature map вырезаем только середину.
Как раз вопрос про предикш, опять же нахлест был k пикселей? как потом объединялись результаты с соседних тайлов, просто усреднением в области пересечения?
Каждая Fully Convolutional Network грешит тем, что предсказания уменьшают точность при удалении от центра, что обычно решается обрезанием предсказания по краям и / или перехлестом предсказаний.
Из-за чего они возникают? из-за zero padding'а на слоях в самой сети?
Как выбирается нахлест тайлов на которые бьётся вся картинка и padding вокруг тайла при подаче на вход сети, исходя из receptive field самой сети?
Похоже на что то низкоуровневое, мне скорее нужен готовый тул который можно просто под себя настроить, или я не правильно понял, нет ли какого то простого примера?
А так мы пробовали https://github.com/apache/incubator-airflow на том же celery, но как то это всё сложно и непонятно как дебажить.
ternaus Можно про это поподробнее.
>чего не хватает в keras чтобы реализвать GAN?
Тут вот на чистом keras реализуют github.com/eriklindernoren/Keras-GAN/blob/master/cgan/cgan.py
Возможно это правда не очень красиво и ворнинг возникает
Еще пара вопросов чего не хватает в keras чтобы реализвать GAN?
Не хватает variable_scrope чтоб потом взять подмножество переменных для генератора и дискриминатора?
generator_vars = tf.get_collection(tf.GraphKeys.TRAINABLE_VARIABLES, "generator")
discrim_vars = tf.get_collection(tf.GraphKeys.TRAINABLE_VARIABLES, "discrim")
Почему мы в при обучении делаем по несколько шагов (`k_step`) для генератора и дискриминатора?
Почему лэйблы добавляются и в discriminator? и зачем нам вообще нужен discriminator если мы можем генерировать изображение по лэйблу просто генератором?
Что такое OOF?
2. Если вы делали end-to-end то почему же сразу не сделали картинка->текст?
В вашем случае k = 16, т.к. 16 сверток 3x3, каждая из которых съедает по пикселю, как было описано выше.
В итоге это избавляет от артефактов на краях тайла.
В U-net судя по пейперу идёт кроп перед каждым пулингом и не описано по какому принципу.
Я изначально имел ввиду что то такое:
Т.е. в зависимости от архитектуры сети можно добить тайл по краям так, чтобы в конце мы получили feature map у которого мы отбросим рамку в 1 пиксель вокруг, а внутреннюю часть возмём, таким образом я предполагаю можно избавится от дефектов.
Судя по пейперу U-net используется unpadded convolutions, но не написано по какому принципу они кропают центральную часть feature map'а.
Тут вот судя по коду на это вообще забили.
Т.е. надо взять тайл изначально большего размера, добив его по краям k/2 pixels от большого изображения, на краях(там где кончается большое изображение) используем отражение.
Так вот насколько я понимаю k это как раз и есть receptive field пикселя с выходного feature map (который имеет меньший spartial размер чем входной тайл) или как высчитать k?
Потом от конечной feature map вырезаем только середину.
Как раз вопрос про предикш, опять же нахлест был k пикселей? как потом объединялись результаты с соседних тайлов, просто усреднением в области пересечения?
Из-за чего они возникают? из-за zero padding'а на слоях в самой сети?
Как выбирается нахлест тайлов на которые бьётся вся картинка и padding вокруг тайла при подаче на вход сети, исходя из receptive field самой сети?
https://github.com/tschnz/Realtime-Video-Magnification
AlexNet
GoogLeNet
NetworkInNetwork
ResNet-50
ResNet-101
SqeezeNet_v1.1
VGG16
VGG19
Average Forward pass: 9.08378 ms.
Average Forward pass: 23.7814 ms.
Average Forward pass: 6.9389 ms.
Average Forward pass: 44.6524 ms.
Average Forward pass: 82.9058 ms.
Average Forward pass: 5.77556 ms.
Average Forward pass: 55.3113 ms.
Average Forward pass: 67.9204 ms.
А так мы пробовали https://github.com/apache/incubator-airflow на том же celery, но как то это всё сложно и непонятно как дебажить.