5
$\begingroup$

i don't get why people close virtually good questions about salient topics to signal processing. an efficient median filter is definitely a salient topic to DSP.

$\endgroup$
7
  • $\begingroup$ Yeah, I'm not really sure why that would be considered off-topic. I guess it did read a little like a "gimme the c0dez" question, but I don't think that was the OP's intent in this case. $\endgroup$
    – datageist Mod
    Commented Dec 18, 2016 at 3:05
  • $\begingroup$ well, whatever the OP's intent (and i do not object to posting code), it's a legit topic. $\endgroup$ Commented Dec 18, 2016 at 3:10
  • $\begingroup$ There's no objection to posting code as long as the focus is mostly on the signal processing and not just on some API (for example). And that seems to be the case here. $\endgroup$
    – datageist Mod
    Commented Dec 18, 2016 at 3:15
  • $\begingroup$ yeah, the guy wants to know how to do a sliding median filter. and so do i. (i actually know how to do a bone-head sliding median filter and am just now learning how to do an efficient one that is $O(\log_2(N)$). $\endgroup$ Commented Dec 18, 2016 at 5:30
  • $\begingroup$ It's this question right: dsp.stackexchange.com/questions/36348/… $\endgroup$ Commented Dec 30, 2016 at 23:35
  • $\begingroup$ yes @OlliNiemitalo $\endgroup$ Commented Dec 30, 2016 at 23:58
  • $\begingroup$ Link to the question in question? $\endgroup$
    – DanielSank
    Commented Dec 31, 2016 at 5:29

2 Answers 2

3
$\begingroup$

Robert, I closed it because, as the close reason states,

Questions requesting working code written to a specification are off-topic as they are unlikely to benefit anyone else. Instead, describe the problem you're solving and where you're stuck.

The OP gave no motivation, showed no interest in letting us know how far they'd gotten, or whether they even understood what a median filter was.

To me, this question is the perfect exemplar of questions that should be closed for this reason.

Feel free to edit it to address these issues.

$\endgroup$
8
  • 1
    $\begingroup$ Oh I completely get why you closed it. Thanks for the excellent explanation of what I obliquely referred to as a "gimme the c0dez" question. In this case, with just a slight amount of effort, it could become a very good question. I'll leave it to you to make the call on when that standard has been met. $\endgroup$
    – datageist Mod
    Commented Dec 18, 2016 at 17:42
  • $\begingroup$ Legitimate closing!! $\endgroup$ Commented Dec 18, 2016 at 19:48
  • $\begingroup$ so because the OP didn't ask nicely and was clueless for how to begin, no one other than me gets to answer that question. $\endgroup$ Commented Dec 18, 2016 at 19:49
  • $\begingroup$ No, @robertbristow-johnson I be glad to spend some time answering it if it's edited $\endgroup$ Commented Dec 18, 2016 at 19:54
  • $\begingroup$ @robertbristow-johnson I believe you shouldn't have answers it without further no clarification. So, to answer your question: yes. $\endgroup$
    – Peter K. Mod
    Commented Dec 18, 2016 at 20:35
  • 1
    $\begingroup$ Could we allow requests for code for general-purpose algorithms? For them the reason to close: "unlikely to benefit anyone else" does not apply I think. Source code can often be employed easier than math or verbal descriptions. Coincidentally, I happen to need a sliding median filter too (really!). $\endgroup$ Commented Dec 30, 2016 at 23:52
  • 1
    $\begingroup$ @OlliNiemitalo : I'm not averse to "reference implementations". I'm just not sure how to distinguish between that and "give me teh codez" sorts of questions. I tend to try to give implementations of algorithms that I answer with; I find if I don't then I miss something about the question. :-) $\endgroup$
    – Peter K. Mod
    Commented Dec 31, 2016 at 0:20
  • $\begingroup$ Ah, I see help center says "specific requests for reference implementations of signal processing algorithms are on-topic". I'll try to edit the question. $\endgroup$ Commented Dec 31, 2016 at 0:52
0
$\begingroup$

How to build a median filter function in 1D can be quite legitimate: nature of the samples (from few bits to double-float), off-line or on-line, $\mathcal{O}(1)$ and constant-time algorithms, using prior or histograms, a comparison between the performance wrt languages or memory, build it from stack filters, etc.

Closing a question can be a question of rules, habits and mood, so it is not 100% logical. I did not vote to close it (but I could have done so if fast enough and in a bad mood), and I am not sure that off-topic is a perfect match, but tickable reasons for closing are limited.

But this question, at least in the present version, is quite poor. We shall extrapolate that it is a running median. Easy. Apart from that, in my opinion, it is written written like mandatory (I need to build one) homework (without using medfilt1 or any matlab funct) unthought (How to build a median vs 1D median filter algorithm) request (Help me). The OP does not make a distinction between the median definition, algorithm or its implementation. I do teach DSP, and I ask students on the first day to implement, by themselves and from scratch, a running mean and a running median, to evaluate their abstraction, validation, coding and efficiency skills.

With such a question, you can ignore, edit or close. Putting ignore aside, to me the options for improving the quality of SE.DSP are either:

  • edit ANY question, because ANY question can be turned into a good question, and answer it the best you can,
  • comment, flag, close, and offer the OP a chance for improvement.

The limit between the two options belongs to your power of interpretation.

As a side note, your present question does not seem to be a question:

  • Neither the title nor the body contain a question: you object, ok, that is a personal position, you don't get, a matter of fact
  • The title is about something quite specific (i object to the median filter question being closed) and the body is quite generic, so very different: why people close virtually good questions.

Yet I agree, an efficient median filter is definitely a salient topic to DSP. So what should I do with you question? I did not ignore it. Should I edit it? Flag it? I do love recursive arguments and embeddings.

$\endgroup$
4
  • 1
    $\begingroup$ Laurent, in this answer i have some very simple, yet efficient C code for computing a sliding max that is $O\big(\log_2(N)\big)$ in computational cost. it can be simply modified to perform sliding min. since i have seen some efficient median algorithms that are $O\big(\log_2(N)\big)$, but there is a lot of indirection in the code that, while proportional to $O\big(\log_2(N)\big)$ would slow it down, in my opinion. $\endgroup$ Commented Dec 26, 2016 at 18:28
  • $\begingroup$ the way i might do it is to maintain two buffers, a sliding max, operating on the data that is below the median, and a sliding min, operating on the data that is above the median. both buffers are long enough for the entire window, but in the lower buffer all of the samples that are above the median will be assigned something like -1.0e38 and in the upper buffer all of the samples that are below the median would be assigned +1.0e38. that way, the sliding min or sliding max always gives us the two samples sitting right next to the median. $\endgroup$ Commented Dec 26, 2016 at 18:32
  • $\begingroup$ @robert bristow-johnson I believe that most of the discussion is about the question, not your answer $\endgroup$ Commented Dec 26, 2016 at 18:33
  • $\begingroup$ so, when a sample comes in, you have to decide which buffer (the lower or upper) it goes into (and $\pm$1.0e38 goes into the other buffer. then if the sample that falls offa the edge is in the same buffer, there need be no transfer between the upper and lower. but if the sample that falls offa the edge is in the opposite buffer than the new sample coming in, then a transfer must be made. $\endgroup$ Commented Dec 26, 2016 at 18:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .