Cafe RadLab

Full Version: Gamma on Cam - Analysis
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
As has been discussed in the thread 'Gamma on Cam', it may be possible to get a general idea of radiation readings based on gamma distortions on the Tepco Webcams. This thread will document the process and record all results.

What are we doing and why?
We need to count the gamma distortion dots on videos to create the baseline data. This process will help establish a known baseline dataset to be used to calculate radiation readings from the Tepco Webcams.

This is the most complicated part. We want to record the information as accurately as possible to get the best results. This means we must account for many things when counting and recording results. The specifics of that will be detailed later, for now, lets get an idea of how counting works.

To make a calculation of an 'unknown', we'll need to know a related 'known' to make a linear comparison. This is very basic and simple approach.

We know that gamma can make a distortion on digital camera CCDs and this can be witnessed as 'dots' or 'sparks' in the video. For this analysis we'll have to ignore beta and alpha radiation as these probably cannot reach the digital camera CCD. What we need to know is: how much gamma radiation produces how many dots.

If we have a video that provides a rate of radiation of the video being filmed, and shows the distortions, we can create a ration between the number of dots and the reading.

The following videos provide all that we need to get started:
Download link
Download link
Download link
Download link

The counting process:
To show the process, I'll demonstrate with my first try.
To start I downloaded one of the videos above (150420_02j). I played the video until the video showed a good portion of the frame providing good contrast to show the 'dots' ( dark backgrounds are the best). I then captured 5 frames from the video and saved them.

Here is one of the frames I captured for analysis:

Cropping to sample size:
First, lets cover Cropping the captured frames. We need to eliminate areas of the frame where we won't be able to see the gamma distortion 'dots'. These are areas that contain text overlays, light reflections, bright objects or high contrast patterns that would hide the light colored 'dots'.

To give you an idea of the areas we want to avoid, I've highlighted the bad areas in red in this image:

To make things easy, we'll just crop the image to s smaller rectangle area to shown only the area we want to count. When we crop the video frame, we want to make sure we get as big of an area as possible. the largest area I see is the upper left of the frame. I've shown the area in a red box here:

Before cropping, I made note of the sample size of the frame in pixels. As you can see it is 574 x 347 pixels. This will be an important number later, so this must be known and documented. Then I cropped all 5 frames to the same size area I wanted to sample and then began counting...

I used the paintbrush tool to mark each dot I counted, and changed the color every 10 dots so it was easy to total up.

Here are the remaining 4 samples I counted:


Now we have a count on 5 frames. From here we'll be doing calculations to make the data as useable as we can. There are a number of factors to consider for the data we just recorded.

First we need to know the sample resolution. This was the size we cropped the video frame to. In the case above, it was 574 x 347 pixels.

Quote:UPDATE #1:
These two numbers are entered into the spreadsheet cells B5 and B6

Next we'll need to know the frame rate. This could be anywhere between 4FPS and 30FPS. To figure out frame rate, some media players will tell you information about the video and give you the video FPS. This is a good start, but it may not be the actual frame rate. It is possible some frames of the video are duplicated to make a faster framerate than is actually viewed. This is a video compression technique. We can step through each frame of 1 second of the video and count the duplicated frames. For example:
If the video is 30FPS, and we found 10 frames were duplicated (20 frames total) in one second, then we know we are actually watching 20FPS.

We need to know the actual FPS and not the video FPS. This is a factor when comparing video data later for calculations.
Quote:UPDATE #1:
The actual framerate is entered into the spreadsheet in cell B12

Next are a few other factors that will affect calculations too:
  • We need to know if the video is in real-time, or if it was a time-lapse or slow-motion.
  • We need to know if the video was re-sized and determine how much. 
Quote:UPDATE #1:
These are cells B8 and B12. There are comments in the spreadsheet to help with determining these values also.

Generally we can assume videos are real-time, meaning, 1 second of video is the same as 1 second in real-time.

For resizing, this may be a little more tricky to figure out, but is important for our concerns. I can detail this a little more if there are questions on this factor.

Quote:UPDATE #1:

I forgot the most important part! Data entry.

The count of each sample is entered into the red cells in the Sampling Data section (Cells B18-B22). With each sample count, we're also recording the dose rate. In the case of my first samples, the dose remained constant at 5.7Sv/h for each frame. This rate is entered for each sample in Cells E18-E22.

**For samples that have doses in mSv/h, the rate will need to be multiplied by 1000 to get Sv/h

To make things easier, I've created a spreadsheet for entry of this data.

Quote:UPDATE #1:
I forgot to mention, only cells that have a RED background are for entering data. Yellow colored cells are calculated data.

Have a look at the attached Example form to see how the data recorded and video information was entered into the spreadsheet.

Quote:UPDATE #1:
This spreadsheet does several calculations based on the entered data (Red cells). As you may notice, at the bottom of the form are two values. We see the final ratio in Green. I've picked a ratio I call CPM per mSv/h. This is essentially the 'Count of Dots' in one minutes time that are equal to 1mSv/h. To say that another way, if we had a known radiation field of 1mSv/hr, we would expect to see the same 'Count of Dots' in one minutes time.

This value is a condensed number that is more portable than all of the recorded data. It tells us the sum of all of the data in one number. Once we have established this value for each video analysis, it will be used in the larger dataset to 'normalize' the CPM per mSv/h value.

My initial analysis has resolved the data I collected to 27.584 CPM per mSv/h. This means if we counted ~27.5 CPM in a pixel area the size of our sampling from this video, we should expect a actual dose measurement of 1mSv/h.

Additionally you will notice another special calculated number: Sampling Score
This special factor is also used to normalize the results. it's based on the sample size in pixels and the frame rate. Since all samples will vary in size and cameras will vary in frame rate, we can use this score to better compare the samples.

To do your own analysis, use the same process above, and use the 'blank' form attached below.

Please submit all results to this thread. Include the filled out form and also include sample images used if possible.
(04-12-2016, 11:12 AM)piajensen Wrote: [ -> ]That looks to be a time consuming project for folks with good computer set ups. Is this a tested hypothesis to achieve the stated goal?

I'm not clear on the direction of your question, can you expand on what you are asking?

I realize the analysis process I've proposed may appear daunting and complicated. It wasn't intended to be a process exclusive to people having anything more than a standard desktop or laptop computer. The idea of having others participate is to stress test the process and hopefully expand everyone's knowledge on the topic in addition to gathering the needed data to make assessments on what is witnessed on the tepco webcams.
The procedure above is simply to build a data set we can pull from to make the calculations necessary to make a ROUGH determination of dose at the site of the tepco webcams. This process isn't stand-alone and is intended to be the input(s) for the calculation of ROUGH dose. I'm expecting that the discussion and calculations of dose will be added to the original 'Gamma on Cam' thread. I don't have all my ideas written up yet on either topic, so maybe the passage of time will expose more of what is going on here?

The point of this thread/exercise is to build the data set. To my knowledge this data is not readily available online, so we are attempting to manufacture some baseline data of dose vs. CCD distortions. Radiation distorting CCDs is well documented and has been  implemented into measurement devices already. We're not trying to re-invent that wheel, just extrapolate data based on that phenomenon.

The general purpose in this thread is as I just stated, to build the data set. Others 'stress test' the process by introducing data variations and have questions about things that haven't yet been considered. I don't wan't to go out on a limb and call this a 'scientific' discovery, rather a exercise in research and analysis of existing data to extrapolate what we can not measure. I liken this part of the process is like writing up Log tables that will later be used with trigonometry to calculate how wide a river is while only being able to stand on one side.

As for fitting in to the 'scheme of evaluating emissions' hopefully the above explains that this is part of a bigger process and is not stand-alone. From my perspective it seems to fit with that scheme very well.
No problem, just trying to push my knowledge further and hopefully others as well.

For this general thread, I've made some updates to clarify a couple of things in the original post. Please see the:
Quote:Update #1
quote notes in the original post for my follow-ups.
I've been working on this analysis process and have an update on how to determine frame rates with VLC.

The process to determine frame rates with VLC is as follows:
Load video to analyze
Pause at time desired to analyze.
Enable 'Advanced Controls' from the view menu
Use the frame step button to step through each frame.
Locate and watch the time counter in the lower right corner of the VLC window.
Begin by clicking the frame step button until the second changes to the next second (digit). Don't click too fast or you might pass the frame.
Once you've fount the first frame of the second, start clicking the frame button and counting (2, 3, 4...) until you reach the next second in the video. 
As you click through the frames, watch the seconds but also observe the video frame. some frames may not change for 2 clicks. These are the excess frames we're trying to subtract out.

For the video analyzed above, I analyzed 4 different seconds of the video. From the analysis, I found that the video is 30FPS but only 25 frames in 30 were unique. 5 frames were duplicated and in very predictable timing. Almost every time the sequence of frames was 4 unique frames and 2 frames that were the same. This is the ratio 5/6, so five unique frames in 6 total frames.

Sampling multiple seconds revealed that the timing isn't always consistent. One seconds contained 31 frames and another contained 29. I attribute the variation to the final compression applied to the video (conversion to WMV). Also, the video time compared to the time displayed IN the video were not synced. It was close but not predictable. I'm not quite sure if this needs to be factored in. For now, I'm going to say it's close enough to move forward.

On an interesting side note, as I was sampling seconds in the  150420_02j video, at time 0:52-0:60 (1min) the dose rate suddenly jumps from ~6sv/h up to over 40sv/h during that time. Could the bot be passing over some fuel that escaped at that point in the video? As the bot moves on, the dose rate drops back to around 6sv/h.