Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Outputs are nan given a big window shape in iterator #3

Open
GlowingHorse opened this issue Aug 10, 2020 · 3 comments
Open

Outputs are nan given a big window shape in iterator #3

GlowingHorse opened this issue Aug 10, 2020 · 3 comments

Comments

@GlowingHorse
Copy link

When I run DASP on a convolutional neural network (mnist dataset), I found something weird.
If I use a ImagePlayerIterator with a big window_shape (like 1/4 of the image size), then y1 and y2 will produce nan.

y1, y2 = self.dasp_model.predict(inputs, batch_size=batch_size)
y1 = y1.reshape(len(ks), x.shape[0], -1, 2)
y2 = y2.reshape(len(ks), x.shape[0], -1, 2)

I tried to check if something like delta (0.0001) is missing in denominator or divisor, but it seems like no problem in codes of all lpdn or dasp layers.
Have you any idea about this? Thanks in advance.

@GlowingHorse
Copy link
Author

Seems like some zero padding makes the output conv_count of the conv operation at zero.
-> dasp/layers/convolution.py
conv_count = self._conv2d(ghost, tf.ones_like(self.kernel))

I just add this
conv_count = tf.maximum(conv_count, tf.reduce_sum(tf.ones_like(self.kernel)))
after it. Is it same with your original thought?

@marcoancona
Copy link
Owner

marcoancona commented Aug 11, 2020

Hi! It is still not clear to me how the result conv_count can be zero because both the input (ghost) and the kernel are made of ones.

EDIT: I did not see your mention to zero-padding. Your solution seems to make sense indeed.

@sebp
Copy link

sebp commented Aug 21, 2020

I encountered the same issue. It also occurs when using an ImagePlayerIterator with the spatial dimensions of window_shape set to the kernel size of the first convolutional layer. In that case, conv_count will yield zero for the patch currently masked out, because the shape of the masked elements exactly matches that of the kernel size.

I'm not sure whether the fix proposed by @GlowingHorse would work. When taking the maximum, wouldn't conv_count always be the kernel size, disregarding the actual mask?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants