Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 16 18:26
  • Jan 11 20:55
    hmwill starred boostorg/gil
  • Jan 11 06:51
    shahpratham starred boostorg/gil
  • Jan 07 20:07
    mloskot labeled #616
  • Jan 07 20:07
    mloskot milestoned #616
  • Jan 03 17:16
    lpranam commented #573
  • Jan 03 16:46
    mloskot commented #497
  • Dec 31 2021 01:56
    lpranam commented #497
  • Dec 31 2021 01:55
    lpranam commented #497
  • Dec 31 2021 01:55
    lpranam commented #497
  • Dec 30 2021 04:54
    lpranam review_requested #634
  • Dec 30 2021 04:54
    lpranam opened #634
  • Dec 30 2021 04:47
    codecov[bot] commented #573
  • Dec 30 2021 04:47
    lpranam synchronize #573
  • Dec 30 2021 01:53
    codecov[bot] commented #573
  • Dec 30 2021 01:53
    lpranam synchronize #573
  • Dec 26 2021 19:08
    simmplecoder commented #633
  • Dec 25 2021 18:47
    octopus-prime commented #633
  • Dec 25 2021 18:17
    simmplecoder commented #633
  • Dec 25 2021 17:56
    simmplecoder commented #633
Pranam Lashkari
@lpranam
I am a little confused with #391 with all these options when extending the boundary and would like some feedback on it
  1. with option output_ignore and extend_padded it will return the image without any changes
  2. with option output_zero it will do same as extend_zero (extend boundary with 0)
Mateusz Łoskot
@mloskot
@lpranam You are not alone :-)
All those come from the original implementation of the convolution and I once tried to track the implementation in detail to understand exactly what is the rationale/differences of all those, and hopefully document it better.
Mateusz Łoskot
@mloskot
output_ignore and output_zero are more alike; the latter can be seen as a refinement of the former to ignore but with setting pixels to zero
output_zero means setting destination with zero
Mateusz Łoskot
@mloskot
extend_* mean setting source first, then use that refined source to calculate destination values
I'm not quite convinced output_zero and extend_zero are equivalent in general case, can't remember from top of my head.
They certainly are for products in some specific cases.
I will have to look at that convolution/correlation code again and document it
Pranam Lashkari
@lpranam
the most confusing and least convincing thing in convolution/correlation was with extend_padded

https://github.com/boostorg/gil/blob/90f6fc04ed9414c5f640339ec7f5e9972fb3c9b7/include/boost/gil/extension/numeric/convolve.hpp#L117

If we see in this statement pixels accessed are beyond the boundary of view which implies that we pass a sub_view of the original view

Mateusz Łoskot
@mloskot
Regardless of the option, buffer size is always greater than src_view. It is line long for width + kernel.size() - 1
Depending on option pixels are copied from src_view into the buffer at different locations
1 2 3 4 X X X - into the beginning of buffer
X X 1 2 3 4 X X - into middle of buffer as in the padded case (the X-s are the padding`
Ha! I think that is b****it what I wrote
or X X 1 2 3 4 X X is indeed the actual effect of the padded
It's not obvious to me why/how this range is valid though
src_view.row_begin(y) - kernel.left_size(),
src_view.row_end(y) + kernel.right_size()
I must be missing some critical magic
Pranam Lashkari
@lpranam
I think they expect us to pass sub_view of original view
Mateusz Łoskot
@mloskot
In optimal case (somewhere in the middle of the image), that is the case indeed, but I'm thinking of the first iteration, first row/column of image, first application of kernel
Pranam Lashkari
@lpranam
are we going to include Miral's implementation of 2d convolution in 1.72 realse? Cause I am thinking of changing API of it and make it similar to 1d convolution
Once it releases its hard to change the API
Mateusz Łoskot
@mloskot
From my perspective, given there is still plenty to get done (docs!), we are not in rush.
So, we may prefer to take time this year to refine and polish public interfaces of the new features added during GSoC and by others
It would also give us higher chance to complete migration of numeric (and dynamic image) to core, add PNM ASCII support and bring PNM ASCII as built-in format for test images suite used in our tests.
That is why I titled the milestone Boost 1.72+ :)
@stefanseefeld What's your opinion?
Pranam Lashkari
@lpranam
anyways problem with extend_boundary is small one just need to figure out what option would do what!?
Mateusz Łoskot
@mloskot
Insights from any investigation into that will be helpful to document it better
In GIL, I miss ability for old-school printf-like debugging :-)
I think it would be helpful for complex algorithms to be able to run it and monitor intermediate results
This simple technique proved to be powerful for Boost Geometry where it can be enabled with BOOST_GEOMETRY_DEBUG* macros (e.g. BOOST_GEOMETRY_DEBUG_TURNS)
Pranam Lashkari
@lpranam
do you have any idea to move forward in that direction?
Mateusz Łoskot
@mloskot
I imagine hex dump of intermediate results (e.g. the buffer line) during various steps of convolution/correlation for different supported options would be helpful to gain insight about what it does for variety of data inputs, and to verify it does what we expect
Yes, this idea I keep on my back burner, but it's not hight priority
Pranam Lashkari
@lpranam
I'd work on it
Mateusz Łoskot
@mloskot
First, I'd like to get the PNM (ascii) format implemented and moved as built-in format. This would already be an improvement allowing you to dump any image_view in human-friendly form (text)
e.g. view before and after
Plain text is very handy as as device or image viewer independent way of visualising data :)
:point_up: September 18, 2019 7:25 PM
Great, we can collaborate on some prototype.
Something simple, not too overengineered, hidden (not in public namespace), compile-time controlled.
Obviously, such approach has one major disadvantage: a bit of code bloat (i.e. #ifdef, part constructing image_view for intermediate result, dumping it, etc.)
but I personally see more advantages leading to decreased time of debugging bugs
Mateusz Łoskot
@mloskot
I have to run
Pranam Lashkari
@lpranam

Obviously, such approach has one major disadvantage: a bit of code bloat (i.e. #ifdef, part constructing image_view for intermediate result, dumping it, etc.)
but I personally see more advantages leading to decreased time of debugging bugs

simplest things are most elegant sometimes.

But for now, I want to complete the boundary options problem with extend_boundary because I want to use it in 2D Convolution and correlation. Tell me when you get an idea about it
Mateusz Łoskot
@mloskot
An idea about what?
Pranam Lashkari
@lpranam
How each option shoud behave in extend_boundary
Mateusz Łoskot
@mloskot
I think the idea is very close if not equivalent to extend_padded
Mateusz Łoskot
@mloskot

@lpranam I won't be able to say anything sensible before I have clear understanding of all those options myself.
Before I'm clear how each of them affect application of 3x3 X-s kernel in the first pixel position like here

X X X
X Y Y Y Y Y Y
X Y Y Y Y Y Y
  Y Y Y Y Y Y
  Y Y Y Y Y Y
  Y Y Y Y Y Y

This needs a proper documentation, visual, with images or ascii art at least.

@lpranam By the way, OpenCV also uses the same 'border' constants for both, convolution and border construction.
This obviously is a good idea since such border addition, replication etc. is a preparatory step prior convolution
or it is an operation on its own, both doing the very same thing.
Mateusz Łoskot
@mloskot
@lpranam I'd love to get all this investigated and clarified but I won't be able to do anything before some time next week or weekend.
MIRAL SHAH
@miralshah365
I was working on median filter and now I am a bit confused which is the most efficient way to find the median is there any existing function for that? I wanted to use nth_element but it doesn't preserve the original sequence.
Olzhas Zhumabek
@simmplecoder
@miralshah365 there is no better way than copy + nth element as far as I know
since the window is usually small, you might try to just as well sort it then select center index
MIRAL SHAH
@miralshah365
can anyone have a look at #393 I can't figure out what's wrong? It must be something easy and in front of me, that's why somehow it is getting ignored by me.
Mateusz Łoskot
@mloskot
@miralshah365 I'm sorry, I'm a bit busy this week and only worked out emergency fix for our master brach. I will do my best to look at your PR over the weekend.
Olzhas Zhumabek
@simmplecoder
@miralshah365 , I can try, will be ready at 9:30 PM GMT+6, roughly in 1.5 hours