Page 1 of 2

Washed out colours in "motion" folder

Posted: Mon Mar 12, 2007 12:14 pm
by zebra300760
Greeting to YawCams creator. You have created a fine piece of software.

I am using yawcam 0.2.6>7 3/Mar/07 Beta. I am using the motion detector option. I can see that the images stored in MY directory are about 200mS behind the actual event - most probably due to low SPEC CPU system.

I have also noticed that the motion events JPG's are stored in the "motion" folder but record a different picture with no 200mS delay. This is ideal for me.

When I review the JPG's using Windows XP explorer viewer from the "motion" directory the colour is washed out and barely viewable. However, if I use yawcam motion event viewer, the picture are of the normal quality.

Also, if I make a movie from the images store in "motion", the result is a corrupt MOV file.

This is my first experience with YawCam so I have had no previous version installed.

Posted: Tue Mar 13, 2007 8:27 pm
by malun
I have the same behavior with strange colors on the images in the motion directory. I also get corrupt .mov files when I create a movie from these images.

I'll look in to that and see what I can find...

/malun

Posted: Tue Mar 13, 2007 9:44 pm
by zebra300760
that is great. thankyou for your response

Posted: Tue Mar 13, 2007 10:44 pm
by zebra300760
Malun

I have also noticed that the JPG's in the motion folder don't have the overlay applied. In my case just the default time/date

Regards

Posted: Tue Mar 13, 2007 11:12 pm
by malun
zebra300760 wrote:Malun

I have also noticed that the JPG's in the motion folder don't have the overlay applied. In my case just the default time/date

Regards
That's the way it is supposed to be. Or at least that's the way I wanted it to be.
The files in the motion folder was originally only there to have something to show in the event list. My thought was that if you want to save an image when an event occurs you should use the save file action. There you have the option to add the overlay or not.

Now you are reporting a delay on this function and I can see that you want to use the files the motion folder. It might take some time, but I'll see what I can do...

/malun

Posted: Wed Mar 14, 2007 2:15 am
by zebra300760
Maybe a solution to resolve issues (delay ~200mS, washed colour and overlay) is to use the same JPG that is stored in "motion" as the basis of adding the overlay when the user option of save an image is selected, provided that JPG is available in a non-washed out format.

Regards

Posted: Fri Mar 16, 2007 10:47 pm
by malun
Actually, I'm not sure I like that idea.
Feels like the images in the motion directory needs to be "clean".

Optimal would be if the delay in the "save file action" could be reduced even on slower machines...

/malun

Posted: Sun Mar 18, 2007 1:38 pm
by malun
The problems with corrupt images in the motion folder shall now have been fixed in the latest beta.
I have also found a way to reduce the CPU usage for the "save file" action. This will hopefully reduce the delay a bit. ( But I haven't made any tests of this so I can't tell for sure... )

Get the latest beta from here:
http://www.yawcam.com/forum/viewtopic.php?t=599

/malun

Posted: Tue Mar 20, 2007 9:47 pm
by zebra300760
This was a double post. I have removed it. Sorry

Posted: Tue Mar 20, 2007 9:51 pm
by zebra300760
Malun

I can confirm that beta 18/Mar fixes the problem of the washed out colours in the motion directory. It also fixes the problem of the MOV file being corrupted.

The delay shown between the image in the motion directory and my saved image has also been lowered, but in my case it still lags a bit resulting in some loss of content.

I'll play with the sensitivity, tolerance and interval to see what is a good comprimise between CPU usage and time lag

If you check http://tomah.ath.cx/yawcam , you will see an example of what a delay will cause. The car in question is moving at about 20km/h. The difference in the timestamps for the two photos suggests a delay of 260mS.

Posted: Tue Mar 20, 2007 11:17 pm
by malun
zebra300760 wrote:I can confirm that beta 18/Mar fixes the problem of the washed out colours in the motion directory. It also fixes the problem of the MOV file being corrupted.
Good. Thanks for testing.
zebra300760 wrote:I'll play with the sensitivity, tolerance and interval to see what is a good comprimise between CPU usage and time lag
The sensitivity and tolerance shall not affect the CPU usage. Only the detection area, image size and interval do that.
zebra300760 wrote:If you check http://tomah.ath.cx , you will see an example of what a delay will cause. The car in question is moving at about 20km/h. The difference in the timestamps for the two photos suggests a delay of 260mS.
I see your problem. It is not nice at all :evil:
However, I think I have found a way to fix this. It all works very nice in my head, but I haven't actually transformed it into code yet :wink: So who knows how it will work out...

/malun

Posted: Sun Mar 25, 2007 11:00 am
by malun
I have made a new version that should fix the delay.
This will only fix the delay for the first image though. If a series of images is saved all the following images will have some delay. Try it out and see how it works for you:
http://www.yawcam.com/beta/Yawcam_BETA_2007-03-25.exe

/malun

Posted: Sun Mar 25, 2007 11:04 am
by malun
Oh, I forgot to say that the time stamp on the first image saved with the "save file" action will be some milliseconds wrong.

Don't compare the the timestamps between the images in the motion folder and the image saved by the "save file" action. Compare the images instead!

/malun

Posted: Tue Mar 27, 2007 1:32 am
by zebra300760
Thanks. You are very responsive

I have downloaded March-25, but am now at work and it will be night when I get home. I don't think motion detection will work with a nice black image. :shock:

I'll install tonight and check tommorrow.

Posted: Tue Mar 27, 2007 10:03 pm
by malun
It's cool. :D