I think medianBlur should just do nothing in case of the empty input.
BTW .empty() method of the InputArray is more preferable than a null pointer check.

Instead of do nothing it's probably even better to set destination "_dst" to source "_src0" as is already done in case "ksize<=1". So the code becomes shorter and clearer.

@Jejos please, squash commits into one before merge.

@sovrasov: I really tried to squash it as you suggested, but the only thing I found in the github web interface is to squash and merge it in my Jejos/opencv master (what I finally did). I'm not quite sure if my intended final change (simply the content of the last "update smooth.cpp", second part of line 3497) is still in a state of "Pull request". Unfortunately I still see "Commits (4)" in the tab instead of expected "Commits (1)".

You can squash commits using git rebase command. See instruction here.
After the local squash use push -f to publish changes on github.

Thanks for all your help and the link but I ran in a dead end. All I click in the github web interface or type on the command line makes it worse and worse - maybe I need some sleep or a coffee. I yet give up.

I have updated commit of your patch. Please check.

👍

Instead of do nothing it's probably even better to set destination "_dst" to source "_src0" as is already done in case "ksize<=1". So the code becomes shorter and clearer.

I am wondering if this is actually what you want? If src0 is empty, then the function should report this, and not just generate an empty dst matrix. In my opinion it should throw an assertion telling you that the src image is empty and should be filled.

Actually we need to introduce unified behavior for all the functions in imgproc (process empty images quietly or reporting about this via exception). There is no consensus about this issue right now. On the one hand quiet processing may be useful in some high-level algorithms which will use these basic functions. If we have 1x1 image we will do nothing, so we can do the same with 0x0 image by continuity. This will save emptiness check in high-level functions.
On the other hand there are debugging problems and so on.

I agree that consensus is needed, but silently continuing is very dangerous. Debugging what goes wrong in an iteratieve process will be nearly impossible. Can we get some other devs opinions on this?

@alalek: Thank you very much!

@sovrasov, @StevenPuttemans:
On the one hand, if ksize is in the set {1,3,5}, medianBlur neither produces a crash nor an exception but is continuing silently. That's the reason why I finally added the bugfix to behave the same way for odd ksize>=7. I thought, it would be hard to understand for a user why the function accepts an empty input for small ksize but throws an exception for larger values. But on the other hand medianBlur already throws exceptions, e.g. if ksize is not odd. So - why not also throw an exception for larger odd values. Indeed it would help debugging. To make function behavior consistent, an exception should be thrown for ksize in {1,3,5}, too, -- but unfortunately that could break existing code and should be avoided.

My pragmatic conclusion: If you want to manipulate images, an empty input image is useless and typically reveals a buggy program (like mine that crashed before I found the bug) -- an exception is the appropriate reaction of the program and should be thrown where ever it is possible to support debugging.