Closed tjgalvin closed 4 years ago
This has gotten stranger. Looking at the SOM file created by PINK, the neuron dimensions do not look correct to me. I would expect for input images of shape (150,150,2)
that the neuron dimensions would be (213,213,2)
- a factor of 2**0.5 larer. The PINK banner message gets the correct dimensions
Data file = EMU_WISE_Imgs_Circular.bin
Result file = SOM_B1h10_w10_emu.bin
Number of data entries = 192938
Data dimension = 150 x 150 x 2
SOM dimension (width x height x depth) = 10x10x1
SOM size = 100
Number of iterations = 5
Neuron dimension = 213x213
Euclidean distance dimension = 106x106
Data type for euclidean distance calculation = float
Maximal number of progress information prints = 10
Intermediate storage of SOM = keep
Layout = cartesian
Initialization type = random
Interpolation type = bilinear
Seed = 1234
Number of rotations = 92
Use mirrored image = 1
Number of CPU threads = 4
Use CUDA = 1
But the SOM header outputs (2, 1, 0, 0, 2, (10, 10), 0, 3, (150, 150, 2))
. The number of floats in the header appears to be the same as specified by the header.
I was expecting the behavior for these multi-channel images to be the same as Pink v1
, where the neurons would rotated along the center point through each channel simultaneously. The type of behavior expected for a RGB style colour image.
Following the behavior from Pink v1
I would expect in this case that the channels
I'm slowly drilling down into this. I think there there may be a bug in the InputData.cpp
, line 442
m_neuron_dimension = m_data_dimension;
if (m_neuron_dimension.size() == 2) {
m_neuron_dimension[0] = m_neuron_dim;
m_neuron_dimension[1] = m_neuron_dim;
}
I think this comparison should be >=2
to handle the cases where the dimensionality of the data is 3 i.e. (150, 150, 2). Adding this fix and recompiling produces a SOM with the correct (213, 213, 2)` data shape.
It remains to be seen whether this actually produces meaningful SOMs or whether there are other issues later.
So I think that there may be two issues here. One is the initialization of the SOM. When more than one channel is included in the data, (150,150,2)
for example a segmentation fault will be encountered when using --init random_with_preferred_direction
.
else if (input_data.m_init == SOMInitialization::RANDOM_WITH_PREFERRED_DIRECTION) {
fill_random_uniform(&m_data[0], m_data.size(), input_data.m_seed);
for (uint32_t n = 0; n < input_data.m_som_size; ++n)
for (uint32_t i = 0; i < input_data.m_neuron_dim; ++i)
m_data[n * input_data.m_neuron_size + i * input_data.m_neuron_dim + i] = 1.0;
}
This does not seem to be operating over the channel dimension. input_data.m_neuron_size
only seems to be initialized as m_neuron_size = m_neuron_dim * m_neuron_dim
. Should there be an additional depth term in here? Or is there extra bookkeeping elsewhere? The input_data.m_som_size
does not take into account the channels of the data (and neurons).
The second issue seems to be with the SOM itself when there are multiple channels. It looks the like the second channel does not ever get updated and remains the uniform noise it is initialized. From what I can tell the generation of the rotated images and calculation of the euclidean distance seems to be correct, so I am guessing it is with the weighting update. I wanted to create a some of (4,3) neurons.
I am pretty certain the ordering I have read the axes in is not correct. But the important thing to note is the noise that is still present.
Any thoughts? I can try to spend a little more time digging into this if it is a bug. I'm a bit slow as I get myself familiar with the code base. But if the simple answer is Pink v2
does not support three-dimensional data at this time I might have to drop back to an earlier version.
Hi Tim! Thanks for reporting. I will take a look into it and come back to you as soon as I have checked that behavior.
Yes, you are right. Multichannel images are not working in PINK v2. I will fix this in the next days and within v2.4. Sorry for that.
Thanks for that - glad it was not just user error! I'll refrain from trying to debug then - thanks Bernd!
I have fixed now some index inconsistencies in the Cartesian 3D data layout. Because of performance the image transformations were implemented for the fastest indices. This means that the depth (channel) index have to be the first index (d, r, c). It is fixed for the CPU version yet. The GPU version is in process.
See also the jupyter notebook for testing: https://github.com/HITS-AIN/PINK/blob/master/jupyter/notebooks/devel/train-morphology-EFIGI-png.ipynb
I am using an image binary file with about 200k images, with each image having a dimension of (150,150,2).
It seems that when using
--init random_with_preferred_direction
to create the initial map state there is a segmentation fault. Switching this to justrandom
seems to work fine.I am guessing that it has got to do with the third dimension of each image. I have no dug through the code to isolate much more than this at the moment.