Closed aleksati closed 4 years ago
What do you mean by "bug"? Does it create the file? Or is it an empty image? Something else?
Yes! My bad. It always creates the files but it sometimes renders them as blank, only half printed, and sometimes with a lot of "noise", like black lines and dots all over. To me, these mavg files are the only ones that are unreliable when exporting.
ok! smells like a scheduling issue, I will take a look!
Update: I think the reason some mavg videos go black and others are fine is due to the noise reduction threshold value. When I connected a pwindow to the right-most outlet of the [p motion_image] I noticed that with some videos the preview was completely black. Effectively making some exported images black, I believe? However, when changing the threshold, more and more motion was visible in this pwindow and the exported images were not black.
The stream that comes from this right-most outlet is what is used to generate the motiongrams and mavg images. Maybe it should be on the display? This way, the user can actually see what is being used to export their analysis images. And change the threshold and noise reduction accordingly.
Just a thought. What do you think @balintlaczko ?
Alternatively, we can preview one of the motiongrams (maybe the x-axis one) in the UI, in real-time. It would be a great help to see how it looks before exporting, I think.
I will make a separate issue for this preview thing..
The "bugging" seems tot be the same issue as the avg images had with the jit.normalize .. the motiongram without image normalization needs the [jit.op + pass pass pass (at)val 255] to be able to export. which is very strange. It works now, but you should also test on windows when you have time. I have NOT committed yet but will post when I do.
Spent some hours of investigating this, and after trying 23475 different things out, the solution turned out to be super simple... So there seem to be 2 separate problems, one is the weird artifacts on the result (happens to me a lot less often) and the other is the blank image without normalization, and I even noticed a 3rd one where there is output but much more "faint" then what I can see in the [jit.pwindow]. I noticed that very low pixel values get zeroed in the exported image, I thought it's because the compression (which is partly true), but the problem was actually that the matrix we want to export should always be a 4-plane one as a rule. If I send the things in as a 4-plane matrix everything seems to work nice with all the videos I tested it with (also without the weird artifacts). And I think normalization is a must when working with [cv.jit.mean] or at least in the motion average image, since the pixel differences between frames are often very-very small, and very-very "dim" pixels do seem to be dropped by the image compression algos. @AleksanderTidemann should I push the fix?
Tested now again with -bball.mov -blading.mov -dance.avi -pianist.avi -test.mov (my own screen capture) and I get good results with all of them - though normalization seems to be crucial for anything working with the motion image, which makes sense. I will push these changes in a separate file, just in case. I will do my other work in there as well, (the menubar, fixing some aspect ratio stuff) and then we can decide later what to merge, and what not to.
Yes, good work :) Very strange issue. I agree. I have also made a way to export the motion images in color and to choose between file formats. It´s not quite done yet, but I can push it now if you want? Or is it easier for you to work on a separate patch and then we merge later?
Great! Yeah, push it, don't worry, I will just do my changes in the patch with the "_B" suffix just so that we avoid collisions when both of us are pushing at the same time, and then we can have a merging session in January when I come back to Oslo, OK?
Sounds good!
This is further elaborated on in issue #53
This might be due to [jit.normalize] in motion image abstraction.