Map initialisation with random noise and prefered direction

[tjgalvin]

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 just random 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.

[tjgalvin]

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

[tjgalvin]

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.

[tjgalvin]

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.

[BerndDoser]

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.

[BerndDoser]

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.

[tjgalvin]

Thanks for that - glad it was not just user error! I'll refrain from trying to debug then - thanks Bernd!

[BerndDoser]

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.

[BerndDoser]

See also the jupyter notebook for testing: https://github.com/HITS-AIN/PINK/blob/master/jupyter/notebooks/devel/train-morphology-EFIGI-png.ipynb