Implement Sobel and Scharr operators #392

simmplecoder · 2019-09-24T18:43:22Z

Description

This commit adds Sobel and Scharr
operators with support for 0th and 1st
degrees with other degrees planned for
later

References

https://www.researchgate.net/publication/239398674_An_Isotropic_3_3_Image_Gradient_Operator

https://www.researchgate.net/profile/Hanno_Scharr/publication/220955743_Optimal_Filters_for_Extended_Optical_Flow/links/004635151972eda98f000000/Optimal-Filters-for-Extended-Optical-Flow.pdf

Tasklist

Implement the operators
Add test case(s)
Ensure all CI builds pass
Review and approve

example/Jamfile

include/boost/gil/detail/math.hpp

include/boost/gil/image_processing/numeric.hpp

test/core/image_processing/sobel_scharr.cpp

stefanseefeld · 2019-10-01T20:13:10Z

yes, yes, I still plan to refactor the code so the numeric extension will be fused into core. Sorry for my slowness... :-(

mloskot · 2019-10-01T20:17:41Z

@stefanseefeld

I still plan to refactor the code so the numeric extension will be fused into core

Okay, so if @simmplecoder doesn't prefer to do it now, then we can split numeric.hpp into multiple headers during or after the fuse.

mloskot

@simmplecoder LGTM.

However, please ask and wait for @stefanseefeld 's review and consider his review superior to mine.

simmplecoder · 2019-10-22T16:37:21Z

@stefanseefeld , would you like me to unify the interface of all kernel generator functions in this PR?

stefanseefeld · 2019-10-22T17:38:37Z

@simmplecoder , sorry, I don't entirely understand the question. What do you mean by "unify" ?

simmplecoder · 2019-10-22T17:43:52Z

@stefanseefeld, earlier functions that generate Gaussian and mean kernels return image_view, while these return kernel_2d. Would you like me to make all functions return kernel_2d?

stefanseefeld · 2019-10-22T17:44:41Z

Ah, yes, I think that would be preferable. Thanks,

mloskot · 2019-10-22T17:57:51Z

@stefanseefeld

Ah, yes, I think that would be preferable.

I agree that it's better to (create and) use dedicated types for job than trying to (bend to) re-use existing types where they don't necessarily fit, neither conceptually nor physically.
Another aspect is that if we use types like image_view as general-purpose types we are somewhat tightening the coupling between functions operating on kernels and image_view preventing treating those as completely independent entities. This may cause problems in future (e.g. it may be hard to change either).

simmplecoder · 2019-10-23T06:16:41Z

@miralshah365 , could you please check if I broke your code? I migrated small part of your code that relied on old image_view interface for kernel generators.

simmplecoder · 2019-10-23T07:24:53Z

The output of Harris and Hessian seem to be differ from before the migration to kernel_2d. I will investigate that further, but I believe the interface should be more or less stable now. Hopefully I will be able to find what's wrong until the deadline.

mloskot · 2019-10-23T09:55:14Z

@simmplecoder If there is anything to update in @miralshah365 's code and she's offline, then don't hesitate to nudge me. I will try to take care of updating Miral's code.

AFAIS, current failures are in the kernel tests, see https://dev.azure.com/boostorg/gil/_build/results?buildId=701&view=logs&jobId=2517ed61-6924-508d-087f-7c02f775cbba

 "D:\a\1\s\boost-root\libs\gil\_build\test\core\image_processing\test_core_image_processing_simple_kernels.vcxproj" (default target) (26) ->
       (ClCompile target) -> 
         d:\a\1\s\boost-root\libs\gil\test\core\image_processing\simple_kernels.cpp(20): error C2664: 'boost::gil::kernel_2d<float,std::allocator<T>> boost::gil::generate_normalized_mean<float,std::allocator<T>>(size_t)': cannot convert argument 1 from 'boost::gil::image_view<boost::gil::gray32f_loc_t>' to 'size_t' [D:\a\1\s\boost-root\libs\gil\_build\test\core\image_processing\test_core_image_processing_simple_kernels.vcxproj]
         d:\a\1\s\boost-root\libs\gil\test\core\image_processing\simple_kernels.cpp(39): error C2664: 'boost::gil::kernel_2d<float,std::allocator<T>> boost::gil::generate_normalized_mean<float,std::allocator<T>>(size_t)': cannot convert argument 1 from 'boost::gil::image_view<boost::gil::gray32f_loc_t>' to 'size_t' [D:\a\1\s\boost-root\libs\gil\_build\test\core\image_processing\test_core_image_processing_simple_kernels.vcxproj]
         d:\a\1\s\boost-root\libs\gil\test\core\image_processing\simple_kernels.cpp(51): error C2664: 'boost::gil::kernel_2d<float,std::allocator<T>> boost::gil::generate_unnormalized_mean<float,std::allocator<T>>(size_t)': cannot convert argument 1 from 'boost::gil::image_view<boost::gil::gray32f_loc_t>' to 'size_t' [D:\a\1\s\boost-root\libs\gil\_build\test\core\image_processing\test_core_image_processing_simple_kernels.vcxproj]
         d:\a\1\s\boost-root\libs\gil\test\core\image_processing\simple_kernels.cpp(69): error C2664: 'boost::gil::kernel_2d<float,std::allocator<T>> boost::gil::generate_unnormalized_mean<float,std::allocator<T>>(size_t)': cannot convert argument 1 from 'boost::gil::image_view<boost::gil::gray32f_loc_t>' to 'size_t' [D:\a\1\s\boost-root\libs\gil\_build\test\core\image_processing\test_core_image_processing_simple_kernels.vcxproj]
         d:\a\1\s\boost-root\libs\gil\test\core\image_processing\simple_kernels.cpp(81): error C2664: 'boost::gil::kernel_2d<float,std::allocator<T>> boost::gil::generate_gaussian_kernel<float,std::allocator<T>>(size_t,double)': cannot convert argument 1 from 'boost::gil::image_view<boost::gil::gray32f_loc_t>' to 'size_t' [D:\a\1\s\boost-root\libs\gil\_build\test\core\image_processing\test_core_image_processing_simple_kernels.vcxproj]
         d:\a\1\s\boost-root\libs\gil\test\core\image_processing\simple_kernels.cpp(114): error C2664: 'boost::gil::kernel_2d<float,std::allocator<T>> boost::gil::generate_gaussian_kernel<float,std::allocator<T>>(size_t,double)': cannot convert argument 1 from 'boost::gil::image_view<boost::gil::gray32f_loc_t>' to 'size_t' [D:\a\1\s\boost-root\libs\gil\_build\test\core\image_processing\test_core_image_processing_simple_kernels.vcxproj]

simmplecoder · 2019-10-23T15:35:12Z

@mloskot, I made a lot of changes after your approval, could you please have a look at new changes?

simmplecoder · 2019-10-23T15:56:34Z

FYI, I checked the output of the Harris and Hessian with cmp --silent $old $new || echo "files are different" of commits 5abd20e (needs fixing cmake due to my bad rebase) and 42a3ea0, the files are identical

simmplecoder · 2019-10-23T15:58:27Z

@stefanseefeld , I believe I did all the changes I wanted. The PR is ready for review.

mloskot

LGTM. Thank you!

mloskot · 2019-10-23T19:01:53Z

include/boost/gil/image_processing/harris.hpp

@@ -42,7 +44,7 @@ void compute_harris_responses(
            " tensor from the same image");
    }

-    auto const window_length = weights.dimensions().x;
+    auto const window_length = weights.size();


Minor naming remark: wouldn't width or x_size fit better as name here than length?

mloskot · 2019-10-23T19:06:34Z

include/boost/gil/image_processing/hessian.hpp

 inline void compute_hessian_responses(
    GradientView ddxx,
    GradientView dxdy,
    GradientView ddyy,
-    Weights weights,
+    const kernel_2d<T, Allocator>& weights,


Minor stylistic remark: since in C++ this reads from right to left as "weights is a reference to const kernel_2d object", as we do it for pointers, this should be the East Const way: kernel_2d<T, Allocator> const& weights

You may want to join the revolution! 😉

include/boost/gil/image_processing/numeric.hpp

mloskot · 2019-10-23T19:25:06Z

include/boost/gil/image_processing/numeric.hpp

 /// \brief Generate mean kernel
 /// \ingroup ImageProcessingMath
 ///
 /// Fills supplied view with normalized mean
 /// in which all entries will be equal to
 /// \code 1 / (dst.size()) \endcode
-inline void generate_normalized_mean(boost::gil::gray32f_view_t dst)
+template <typename T = float, typename Allocator = std::allocator<T>>
+inline kernel_2d<T, Allocator> generate_normalized_mean(std::size_t side_length)


Again, wouldn't width or x_size fit better as name here than length?

mloskot · 2019-10-23T19:28:26Z

include/boost/gil/image_processing/numeric.hpp

-        }
-    }
-}
-
 /// \brief Generate mean kernel
 /// \ingroup ImageProcessingMath
 ///
 /// Fills supplied view with normalized mean


Perhaps you could run find and replace for /// Fills supplied view changing to /// Fills kernel. This could be done even after merge as single commit with [ci skip] tag in subject line. No need to CI this kind of change.

mloskot · 2019-10-23T19:30:52Z

include/boost/gil/image_processing/numeric.hpp

+        case 1:
+        {
+            kernel_2d<T, Allocator> result(3, 1, 1);
+            std::copy(dx_sobel.begin(), dx_sobel.end(), result.begin());


Since we have compile-time known std::array<float, 9> dx_sobel, this place seems like a good opportunity to add static_assert verifying dx_sobel.size() and BOOST_ASSERT verifying dx_sobel.size() == result.size().

Such assertions would also serve as code comment for a reader who doesn't have to jump to dx_sobel definition.

mloskot · 2019-10-23T19:33:30Z

include/boost/gil/image_processing/numeric.hpp

+        case 1:
+        {
+            kernel_2d<T, Allocator> result(3, 1, 1);
+            std::copy(dx_scharr.begin(), dx_scharr.end(), result.begin());


Similarly, I'd add some assertions.

mloskot · 2019-10-23T19:33:50Z

include/boost/gil/image_processing/numeric.hpp

+        case 1:
+        {
+            kernel_2d<T, Allocator> result(3, 1, 1);
+            std::copy(dy_sobel.begin(), dy_sobel.end(), result.begin());


And assertions here.

mloskot · 2019-10-23T19:34:03Z

include/boost/gil/image_processing/numeric.hpp

+        case 1:
+        {
+            kernel_2d<T, Allocator> result(3, 1, 1);
+            std::copy(dy_scharr.begin(), dy_scharr.end(), result.begin());


And assertions here too 😄

mloskot · 2019-10-23T19:35:32Z

include/boost/gil/image_processing/threshold.hpp

-            [](gray32f_pixel_t pixel) -> float {return pixel.at(std::integral_constant<int, 0>{}); }
-        );
-
+        kernel_2d<float> kernel = generate_gaussian_kernel(kernel_size, 1.0);


kernel_2d<float> const kernel?

This simple addition immediately clears potential reader's question "can a thing be modified by function call that follows?".

Harris and Hessian examples now use new interface for kernel generation

simple_kernels are now using kernel_2d interface

Normalized mean generation had missing return at the end of the function

This commit reacts to kernel_2d, convolve_2d being moved to namespace detail

Sayan-Chaudhuri · 2021-04-06T15:53:17Z

@simmplecoder I was using the sobel operator for gradient along x direction for the photo attached below. The sobel operator is of degree 1. To my surprise, after applying the sobel operator, the pixel values are coming of the magnitude of 65000 in the gradient image. Is it possible? I used the sobel_scharr.cpp file in the example folder of boost gil and simply passed the name of the operator and the name of the picture and the other arguments as mentioned. I tested the same picture by applying sobel in opencv in python and found the pixel values to be as it should be. If you can kindly help me regarding this issue,I will be highly grateful

simmplecoder · 2021-04-06T17:08:58Z

@Sayan-Chaudhuri perhaps you are using unsigned images and views? IIRC the read functions cannot read signed images, but you can convert them into signed or use color_converted_view. The destination view must be signed as well.

simmplecoder · 2021-04-06T18:31:32Z

I will look into it tomorrow and let you know. Perhaps I forgot to update the example or something

Sayan-Chaudhuri · 2021-04-06T19:15:08Z

Thanks for taking out time to look into the matter

meshtag · 2021-04-07T02:56:38Z

@simmplecoder @Sayan-Chaudhuri , I believe the issue was caused due to 16 in
gil::gray16_image_t dx_image(input_image.dimensions()); and gil::gray16_image_t dy_image(input_image.dimensions());.
Changing them to gil::gray8_image_t dx_image(input_image.dimensions()) and gil::gray8_image_t dy_image(input_image.dimensions()) solved the problem.

meshtag · 2021-04-07T02:59:38Z

@simmplecoder , perhaps we can add a check inside convolve_2d() for handling such things? Is it a good idea to use channel_traits for this purpose? (/cc @mloskot @lpranam )

Sayan-Chaudhuri · 2021-04-07T03:00:46Z

Yes, I also found that but why did this happen?

Sayan-Chaudhuri · 2021-04-07T03:01:01Z

@meshtag

meshtag · 2021-04-07T03:04:39Z

Without doing an in depth analysis, my initial thoughts suggest that we are probably looking at some kind of an overflow inside convolve_2d(). I will have to test it more in order to reach to a conclusive reason.

Sayan-Chaudhuri · 2021-04-07T03:30:37Z

Should I make a pull request if i find out the reason and solve it?@meshtag

meshtag · 2021-04-07T03:45:45Z

I am waiting for feedback on this. If we all agree on the root cause of this problem and my suggestion to solve it, I would like to create a PR myself. Lets wait until we hear from more experienced developers.

Sayan-Chaudhuri · 2021-04-07T04:38:06Z

ok.

simmplecoder · 2021-04-07T04:49:30Z

@meshtag I believe @Scramjet911 didn't have much luck with channel traits. It seems like whatever it returns is not what we need. The problem with the example is that it uses unsigned type where negative values will be present. The fix to use gray8_image_t is wrong, because it uses unsigned type too. I will PR the fix and mention everybody in it this evening.

Scramjet911 · 2021-04-07T05:04:10Z

@meshtag I believe @Scramjet911 didn't have much luck with channel traits. It seems like whatever it returns is not what we need. The problem with the example is that it uses unsigned type where negative values will be present. The fix to use gray8_image_t is wrong, because it uses unsigned type too. I will PR the fix and mention everybody in it this evening.

@simmplecoder Channel traits was working fine, but the problem was that the destination image of that case was of floating type, giving me the wrong result. So I had to use the source channel traits for checking the constraints.

simmplecoder · 2021-04-07T18:23:30Z

@Sayan-Chaudhuri @meshtag unfortunately I didn't get time to write saturate cast, but you can tweak the equation inside transform_pixels below:

#include <boost/gil/image_processing/numeric.hpp>
#include <boost/gil/extension/io/png.hpp>
#include <boost/gil/extension/numeric/convolve.hpp>
#include <string>
#include <iostream>

namespace gil = boost::gil;

int main(int argc, char* argv[])
{
    if (argc != 5)
    {
        std::cerr << "usage: " << argv[0] << ": <input.png> <sobel|scharr> <output-x.png> <output-y.png>\n";
        return -1;
    }

    gil::gray8_image_t input_image;
    gil::read_image(argv[1], input_image, gil::png_tag{});
    auto input = gil::view(input_image);
    auto filter_type = std::string(argv[2]);

    gil::gray16s_image_t dx_image(input_image.dimensions());
    auto dx = gil::view(dx_image);
    gil::gray16s_image_t dy_image(input_image.dimensions());
    auto dy = gil::view(dy_image);

    auto signed_input = gil::color_converted_view<gil::gray8s_pixel_t>(input);
    if (filter_type == "sobel")
    {
        gil::detail::convolve_2d(signed_input, gil::generate_dx_sobel(1), dx);
        gil::detail::convolve_2d(signed_input, gil::generate_dy_sobel(1), dy);
    }
    else if (filter_type == "scharr")
    {
        gil::detail::convolve_2d(signed_input, gil::generate_dx_scharr(1), dx);
        gil::detail::convolve_2d(signed_input, gil::generate_dy_scharr(1), dy);
    }
    else
    {
        std::cerr << "unrecognized gradient filter type. Must be either sobel or scharr\n";
        return -1;
    }

    gil::gray8_image_t output_image(input_image.dimensions());
    auto output = gil::view(output_image);

    gil::transform_pixels(dx, output, [](const gil::gray16s_pixel_t& dx_pixel) {
        double value = dx_pixel[0];
        return gil::gray8_pixel_t((value - std::numeric_limits<std::int16_t>::min()) / (std::numeric_limits<std::int16_t>::max()) * 255);
    });

    gil::write_view(argv[3], output, gil::png_tag{});

    gil::transform_pixels(dy, output, [](const gil::gray16s_pixel_t& dx_pixel) {
      double value = dx_pixel[0];
      return gil::gray8_pixel_t((value - std::numeric_limits<std::int16_t>::min()) / (std::numeric_limits<std::int16_t>::max()) * 255);
    });
    gil::write_view(argv[4], output, gil::png_tag{});
}

The main problem now is that the values are incorrectly scaled. I bet opencv uses saturate_cast for this, but I'm not sure. I will investigate tomorrow.

Sayan-Chaudhuri · 2021-04-08T03:08:04Z

Thanks @simmplecoder I shall look into it

Sayan-Chaudhuri · 2021-04-08T16:42:13Z

@simmplecoder I wanted to confirm that sobel and scharr currently dont work for multichannel images right?

simmplecoder · 2021-04-08T18:10:46Z

You’re correct. You could use channel views to get it to work for multi channel images.

…

On Thu, 8 Apr 2021 at 22:42 Sayan-Chaudhuri ***@***.***> wrote: @simmplecoder <https://github.com/simmplecoder> I wanted to confirm that sobel and scharr currently dont work for multichannel images right? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#392 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADGZGQC2K6GISVJATSKLNATTHXMHTANCNFSM4I2DNP4Q> .

Sayan-Chaudhuri · 2021-04-09T14:16:21Z

@simmplecoder I think for proper scaling we should be using this formula
NewValue = (((OldValue - OldMin) * (NewMax - NewMin)) / (OldMax - OldMin)) + NewMin right??
In transform pixels function , I think you have used this formula but you have given the denominator wrong

Sayan-Chaudhuri · 2021-04-10T07:17:49Z

@simmplecoder Also,how does the convolution operator in boost deal with pixels at boundaries?

cgringmuth · 2023-02-01T09:04:13Z

@Sayan-Chaudhuri @meshtag unfortunately I didn't get time to write saturate cast, but you can tweak the equation inside transform_pixels below:

#include <boost/gil/image_processing/numeric.hpp>
#include <boost/gil/extension/io/png.hpp>
#include <boost/gil/extension/numeric/convolve.hpp>
#include <string>
#include <iostream>

namespace gil = boost::gil;

int main(int argc, char* argv[])
{
    if (argc != 5)
    {
        std::cerr << "usage: " << argv[0] << ": <input.png> <sobel|scharr> <output-x.png> <output-y.png>\n";
        return -1;
    }

    gil::gray8_image_t input_image;
    gil::read_image(argv[1], input_image, gil::png_tag{});
    auto input = gil::view(input_image);
    auto filter_type = std::string(argv[2]);

    gil::gray16s_image_t dx_image(input_image.dimensions());
    auto dx = gil::view(dx_image);
    gil::gray16s_image_t dy_image(input_image.dimensions());
    auto dy = gil::view(dy_image);

    auto signed_input = gil::color_converted_view<gil::gray8s_pixel_t>(input);
    if (filter_type == "sobel")
    {
        gil::detail::convolve_2d(signed_input, gil::generate_dx_sobel(1), dx);
        gil::detail::convolve_2d(signed_input, gil::generate_dy_sobel(1), dy);
    }
    else if (filter_type == "scharr")
    {
        gil::detail::convolve_2d(signed_input, gil::generate_dx_scharr(1), dx);
        gil::detail::convolve_2d(signed_input, gil::generate_dy_scharr(1), dy);
    }
    else
    {
        std::cerr << "unrecognized gradient filter type. Must be either sobel or scharr\n";
        return -1;
    }

    gil::gray8_image_t output_image(input_image.dimensions());
    auto output = gil::view(output_image);

    gil::transform_pixels(dx, output, [](const gil::gray16s_pixel_t& dx_pixel) {
        double value = dx_pixel[0];
        return gil::gray8_pixel_t((value - std::numeric_limits<std::int16_t>::min()) / (std::numeric_limits<std::int16_t>::max()) * 255);
    });

    gil::write_view(argv[3], output, gil::png_tag{});

    gil::transform_pixels(dy, output, [](const gil::gray16s_pixel_t& dx_pixel) {
      double value = dx_pixel[0];
      return gil::gray8_pixel_t((value - std::numeric_limits<std::int16_t>::min()) / (std::numeric_limits<std::int16_t>::max()) * 255);
    });
    gil::write_view(argv[4], output, gil::png_tag{});
}

The main problem now is that the values are incorrectly scaled. I bet opencv uses saturate_cast for this, but I'm not sure. I will investigate tomorrow.

I think your scaling is not correct. If you move values such that min is 0 then you just cannot scale by max. Also I think it is better to scale based on the range of image instead of the range of pixel type [-32768, 32767]. Imagine your range of your gradient is [-10, 10]. You would barely see them if you subtract -32768 and divide by 32767 . But if you map -10 -> 0 and 10 -> 255 then you can see them clearly. So my idea was to stretch the range of your gradients to max range of output type.

Here is mine version to write to png files

template<typename InputView>
void write_view(const InputView& img, const std::string& filename) {
  gil::gray8_image_t output_image(img.dimensions());
  auto output = gil::view(output_image);

  const auto [minPix, maxPix] = std::minmax_element(img.begin(), img.end());
  const auto minVal = minPix[0];
  const auto maxVal = maxPix[0];
  gil::transform_pixels(img, output, [&minVal, &maxVal](const auto& pix) {
      double value = pix[0];
      return gil::gray8_pixel_t((value - minVal) / (maxVal - minVal) * 255);
  });

  gil::write_view(filename, output, gil::png_tag{});
}

Now you have nice gradients (this image has been used):

dx	dy

However, the dx and dy is still switched because of a bug. Please see this PR #723.

simmplecoder requested review from mloskot and stefanseefeld September 24, 2019 18:43

simmplecoder added status/work-in-progress Do NOT merge yet until this label has been removed! and removed status/work-in-progress Do NOT merge yet until this label has been removed! labels Oct 1, 2019

simmplecoder force-pushed the sobel-scharr branch from 6c2f289 to ec75792 Compare October 1, 2019 18:01

mloskot requested changes Oct 1, 2019

View reviewed changes

simmplecoder force-pushed the sobel-scharr branch from fe91129 to f4f50bf Compare October 2, 2019 16:35

This comment has been minimized.

Sign in to view

mloskot added the cat/feature New feature or functionality label Oct 8, 2019

This comment has been minimized.

Sign in to view

mloskot approved these changes Oct 8, 2019

View reviewed changes

simmplecoder force-pushed the sobel-scharr branch from f4d7ca4 to 3b33f9b Compare October 23, 2019 06:14

simmplecoder requested a review from miralshah365 October 23, 2019 06:15

simmplecoder added the status/work-in-progress Do NOT merge yet until this label has been removed! label Oct 23, 2019

simmplecoder requested a review from mloskot October 23, 2019 15:34

simmplecoder removed the status/work-in-progress Do NOT merge yet until this label has been removed! label Oct 23, 2019

mloskot approved these changes Oct 23, 2019

View reviewed changes

simmplecoder added 4 commits October 29, 2019 20:09

Migrate Harris and Hessian examples

71ac791

Harris and Hessian examples now use new interface for kernel generation

Migrate simple_kernels tests

6c57f00

simple_kernels are now using kernel_2d interface

Add missing return

37ea93e

Normalized mean generation had missing return at the end of the function

Adapt code to namespace move

d2479c4

This commit reacts to kernel_2d, convolve_2d being moved to namespace detail

simmplecoder force-pushed the sobel-scharr branch from 42a3ea0 to d2479c4 Compare October 29, 2019 14:09

stefanseefeld approved these changes Oct 29, 2019

View reviewed changes

simmplecoder merged commit 62379dd into boostorg:develop Oct 29, 2019

simmplecoder deleted the sobel-scharr branch August 1, 2020 20:08

mloskot mentioned this pull request Jan 31, 2023

fix: Convolution in convolve_2d. #723

Merged

3 tasks

Implement Sobel and Scharr operators #392

Implement Sobel and Scharr operators #392

Conversation

simmplecoder commented Sep 24, 2019 • edited Loading

Description

References

Tasklist

stefanseefeld commented Oct 1, 2019

mloskot commented Oct 1, 2019 • edited Loading

This comment has been minimized.

This comment has been minimized.

mloskot left a comment • edited Loading

Choose a reason for hiding this comment

simmplecoder commented Oct 22, 2019

stefanseefeld commented Oct 22, 2019

simmplecoder commented Oct 22, 2019

stefanseefeld commented Oct 22, 2019

mloskot commented Oct 22, 2019

simmplecoder commented Oct 23, 2019

simmplecoder commented Oct 23, 2019

mloskot commented Oct 23, 2019

simmplecoder commented Oct 23, 2019

simmplecoder commented Oct 23, 2019

simmplecoder commented Oct 23, 2019

mloskot left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Sayan-Chaudhuri commented Apr 6, 2021

simmplecoder commented Apr 6, 2021

simmplecoder commented Apr 6, 2021 via email

Sayan-Chaudhuri commented Apr 6, 2021

meshtag commented Apr 7, 2021

meshtag commented Apr 7, 2021 • edited Loading

Sayan-Chaudhuri commented Apr 7, 2021

Sayan-Chaudhuri commented Apr 7, 2021

meshtag commented Apr 7, 2021 • edited Loading

Sayan-Chaudhuri commented Apr 7, 2021

meshtag commented Apr 7, 2021

Sayan-Chaudhuri commented Apr 7, 2021

simmplecoder commented Apr 7, 2021 • edited Loading

Scramjet911 commented Apr 7, 2021 • edited Loading

simmplecoder commented Apr 7, 2021 • edited Loading

Sayan-Chaudhuri commented Apr 8, 2021

Sayan-Chaudhuri commented Apr 8, 2021

simmplecoder commented Apr 8, 2021 via email

Sayan-Chaudhuri commented Apr 9, 2021

Sayan-Chaudhuri commented Apr 10, 2021

cgringmuth commented Feb 1, 2023 • edited Loading

simmplecoder commented Sep 24, 2019 •

edited

Loading

mloskot commented Oct 1, 2019 •

edited

Loading

mloskot left a comment •

edited

Loading

meshtag commented Apr 7, 2021 •

edited

Loading

meshtag commented Apr 7, 2021 •

edited

Loading

simmplecoder commented Apr 7, 2021 •

edited

Loading

Scramjet911 commented Apr 7, 2021 •

edited

Loading

simmplecoder commented Apr 7, 2021 •

edited

Loading

cgringmuth commented Feb 1, 2023 •

edited

Loading