[Horse]

(03-28-2016, 06:24 PM)RodgerRoentgen Wrote: Hey Horse,

Great work identifying and documenting the occurrences over time. I had a thought on how you might be able to VERY ROUGHLY quantify what is being captured.

https://www.youtube.com/watch?v=aR--2dASoJA
The video here was from one of the camera probes going into the primary containment in R2. Early in the video there are a great number of frames inside the PCV that are nearly completely black (in photon light), but show TONS of gamma making noise on the CCD. My take is this is the same effect you are documenting, just an extremely higher radiation field.

Here is my idea on how you could ROUGHLY of determine activity on the webcams.

Start by grabbing a bunch of frames from the video above. For each frame, count the noise spots and average out the number per frame. For a quick reference, I counted 67 dots in one quarter of a frame, so that's roughly 250 noise dots per frame. The video description says readings were over 20mSv/hr. So lets assume 25mSv/hr (maybe more?). If we do a quick calculation, we'll figure out a ration for number of frame dots per mSv. ~250 dots divided by 25mSv= 10. So roughly 10 dots in a frame is 1mSv. Then we'll determine what 1 dot in a frame is about .1mSv. Ok, but we need to figure out one last thing and that is the time interval. In the video above, we are seeing ~250 (again rough estimation on my part) per frame. We'll assume 30 frames per second recording, which means every second there would be about 7500 noise dots we could count. 7500 dots per second = ROUGHLY 25mSv/hr. Now, lets get the time base he same. For this, I'm going to go with seconds, so we want to convert 25mSv/hr to mSv/s. There are 3600 seconds in an hour, so we divide 25/3600 = 0.006944mSv/s
Now we know all of these values are equivalent:
7500 dots per second = 250 dots frame = 25mSv/hr = 0.006944mSv/s = 6.944uSv/[b]s

[/b]With these numbers in mind, you could determine activity by counting the number of frames or seconds between each dot you find on the webcam feed. Lets just go with one more example to determine a scenario of activity on the web cam. If we witness a dot on the frame every 3 seconds (this would be calculated from averaging), we'll convert 30FPS*3seconds = 90 frames, or the fraction 1/90 dots per frame. To convert that to mSv we do the following

1/90dpf dots per frame = .33 dots per second

we know 7500 dots per second = 25mSv/hr, so we set up the ratio 7500/25mSv = .33/.0011mSv/hr

.00111mSv/hr = 1.11uSv/hr or roughly 20x background

again, these were all rough calculations and estimations, but you could refine this process to get a better level of accuracy. Frame rates of the cameras is probably the biggest factor to throw off the calculated results. Other factors are unknown to us, so we just have to make some assumptions.

Excellent Roger, TY for tackling the math conversions.  I'm game, but I admit to being fractionally challenged, let's refine some assumptions and plug in some data.


"Now we know all of these values are equivalent:
7500 dots per second = 250 dots frame = 25mSv/hr = 0.006944mSv/s = 6.944uSv/[b]s"

That's good to know, so when I see 2.5 dots or sparks in a frame that would be .25mSv/hr, assuming 30 frames per second recording, yes?


"We'll assume 30 frames per second recording"  

In my recording of the old streams and the new flowplayer, I see 10 frames/sec.  


"we'll convert 30FPS*3seconds = 90 frames, or the fraction 1/90 dots per frame. To convert that to mSv we do the following  1/90dpf dots per frame = .33 dots per second"

That conversion to mSv lost me, 10fps*3seconds = 30 frames, 1/30dpf dots per frame though.


"If we witness a dot on the frame every 3 seconds"

Using a dot every 3 mins would be 20 sparks/hour.

10fps*180secs = 1800 frames, the fraction 1/1800dpf dots per frame = how many dots per second?

That's why I never attempted these calcs, but I think you're on the right track.  Adjust the frame rate to 10 frames per second, use that in the ratio to figure what 20 sparks an hour would be.

more rough observations
10-15 sparks/hr idling
15-20 sparks/hr usually some emissions
20-30 sparks/hr heavy emissions

Early days, 2011, 2012 in 2x timelapse, I find 30 sparks in a half hour, extrapolating to some 60 sparks/hour.  

Thanks for attempting a rough guess, I've been curious what radiation level the sparks might tell us.  I used to watch the netc readings but they didn't vary much when we could see obvious events occurring at Dai-Ichi. A half dozen monitors around the plant that may have limits to what they can measure; ground monitors at the plant boundaries to keep tabs on radioactive dust.  Most of what goes straight up into the air doesn't get counted or the data isn't public.

Info on frame rates:
http://peripherals.about.com/od/webcamer...eRates.htm

Quote:Once a picture (or frame) is captured by the webcam, it creates a JPEG file of the still image. When the webcam has a low frame rate (15 fps or below), the webcam can only transmit a series of these JPEG still images. When the frame rate is higher than 15 fps, the webcam can actually stream video using the computer's Internet connection. Frame rates generally range from 10 fps to 60 fps. You should try to stay closer to 30 and higher if you don't want very choppy video.
Note: In order to stream video, you not only need a webcam with a decent frame rate (15 fps is the absolute bare minimum), but you also need a high-speed Internet connection.
Although the number on the box may say one thing, what your webcam actually captures may be different. Certain things can affect a webcam's frame rate, such as the capabilities of webcam's software program, exactly what you are trying to record, the resolution of the webcam, and even the amount of light in the room. Likewise, running multiple devices via your computer's USB ports can also slow down the frame rate.

Don't know the frame rate of the cameras or the software they use to stream. Can say that Fuku video looks choppy when watching birds fly. My free version of BB Flashback express records the streams at 10 frames per second.

[Chasaha]

Excellent!

IMO - You're on the right track.  

Maybe a new way of measuring rads directly over the complex.

✓ SPH - Sparks Per Hour

[RodgerRoentgen]

(03-29-2016, 06:13 AM)Horse Wrote: Excellent Roger, TY for tackling the math conversions.  I'm game, but I admit to being fractionally challenged, let's refine some assumptions and plug in some data.

No problem, We can refine the equation to make it easier with inputs. I'm not a formally a mathematician, but the subject interests me and I can generally work my way through the basics. Maybe a real mathematician can step in and make sure were not overlooking something or making extra work for ourselves.

(03-29-2016, 06:13 AM)Horse Wrote: "Now we know all of these values are equivalent:
7500 dots per second = 250 dots frame = 25mSv/hr = 0.006944mSv/s = 6.944uSv/[b]s[/b]"

That's good to know, so when I see 2.5 dots or sparks in a frame that would be .25mSv/hr, assuming 30 frames per second recording, yes?

The short answer is no.

I want to be clear, what I initially proposed is purely theoretical. The numbers were fudged to try out the calculation from an input and get an output. However, before we go any further and make more calculated ESTIMATIONS, we need to better establish the unknowns and assumptions. You have started doing this with making adjustments for frame rates, but we need a lot more data/evidence to make the equation have a meaningful result. Otherwise we are doing ourselves and others a disservice.

The calculation of 1 dot per frame = .1mSv was not based on any hard numbers. To come up with that number I guessed many things. I guessed the following:

• Frame rate FPS
  

I poorly assumed 30 thinking back to NTSC, but clearly the live stream is more like 10

• Dose/Rate
  

The video just had 'over 20mSv/hr' in the description, so I guessed higher @ 25mSv/hr, but again we don't have any idea how accurate that number is.

• Dots per frame
  

even this I really cheated on, I roughly counted the dots in one quarter of one frame. This is a very unreliable number considering we can sample more data to get better averages.

Those 3 values need to be much more refined before we can make any assessments of dose based on dots from the webcam. Here is what we can do to refine these variables.
Ideally we need more 'source calibration' videos or photos. Here is what I mean, we specifically need videos showing the anomaly dots but also showing a geiger counter reading. We need the video evidence strongly tied to a real radiation measurement. We can work from photos also, provided we have an associated reading taken at the same time as the photo.
These videos and photos will serve as our 'source' for 'calibration'. from there , for videos, we need to know:

• Frame rate FPS
  

• Dose/Rate per frame
• Dots per frame
  

Additionally, if we are watching/downloading the video from youtube or other online source (essentially anything not the ORIGINAL recording file), we also have to consider that the video has been re-compressed which is a more subtle factor.

So first, we need to gather videos/photos, showing the dots and have a real world radiation reading. As many as we can get, ideally with very dark backgrounds to better show the anomalies. Once we have a good base data set, we can start counting and developing more accurate ratios in the time domain. There were some good videos of the Quincie bots exploring R1, but sadly they must have shielded the cameras or used special cameras because even in high rad fields, none of the cameras show dot anomalies. It would have been perfect because those videos have the geiger counter readings in the video itself.

Your linked information on frame rates is good information and will help refine the equation. I agree most webcams are more in the 10fps range or lower. I just checked the Tomioka cam and the stream is actually very close to 30fps! But the other traffic cams are really slow, they are more like 1fps...

For the other side of the equation, we'll need to firm up the numbers you observe with the recordings you have made. 10 FPS is reasonable for your recordings. Also consider if you are compressing time when you record, we need to factor that in. For example, if playback is at 2x speed (1 min play = 2 min record), we need to account for that in the FPS value.

(03-29-2016, 06:13 AM)Horse Wrote: In my recording of the old streams and the new flowplayer, I see 10 frames/sec. 

Don't know the frame rate of the cameras or the software they use to stream.  Can say that Fuku video looks choppy when watching birds fly.  My free version of BB Flashback express records the streams at 10 frames per second.

ok, we'll also want to consider the recorded vs. streamed FPS. While you may record @ 10, the stream could be less (or more). One way to check is to step through all 10 frames in 1 second. If there are any frames that are identical, you'll need to subtract the number of duplicates from the total FPS. For example, if in 10 frames, 2 frames are duplicated (4 frames total, 2 individual pairs), then a realized frame rate is 8 FPS.


Once we have more solid number for the above variables, we can tackle these:

(03-29-2016, 06:13 AM)Horse Wrote: more rough observations
10-15 sparks/hr idling
15-20 sparks/hr usually some emissions
20-30 sparks/hr heavy emissions

Early days, 2011, 2012 in 2x timelapse, I find 30 sparks in a half hour, extrapolating to some 60 sparks/hour.  

[Horse]

(03-29-2016, 04:11 PM)RodgerRoentgen Wrote: For the other side of the equation, we'll need to firm up the numbers you observe with the recordings you have made. 10 FPS is reasonable for your recordings. Also consider if you are compressing time when you record, we need to factor that in. For example, if playback is at 2x speed (1 min play = 2 min record), we need to account for that in the FPS value.

Glad you're up for number juggling.  Not compressing time when recording.  Only use 1.5x and 2x for playback to save time.

Quote:ok, we'll also want to consider the recorded vs. streamed FPS. While you may record @ 10, the stream could be less (or more). One way to check is to step through all 10 frames in 1 second. If there are any frames that are identical, you'll need to subtract the number of duplicates from the total FPS. For example, if in 10 frames, 2 frames are duplicated (4 frames total, 2 individual pairs), then a realized frame rate is 8 FPS.

The new tepco stream comes with duplicate frames.  In 10 frames half are duplicates.  That changed with the flowplayer.  In the old streams a spark was one frame; with the flowplayer, sparks are two frames, the extra frame a duplicate.  That’s why I guessed they were adjusting the frame rate on the new flowplayer.  In 10 frames, 5 frames are duplicated so the realized frame rate is 5 fps.  

Quote:The calculation of 1 dot per frame = .1mSv was not based on any hard numbers. To come up with that number I guessed many things. I guessed the following:

• Frame rate FPS
  

I poorly assumed 30 thinking back to NTSC, but clearly the live stream is more like 10

• Dose/Rate
  

The video just had 'over 20mSv/hr' in the description, so I guessed higher @ 25mSv/hr, but again we don't have any idea how accurate that number is.

• Dots per frame
  

even this I really cheated on, I roughly counted the dots in one quarter of one frame. This is a very unreliable number considering we can sample more data to get better averages.

The video of the interior of the reactor was probably taken with a better camera than the tepco feeds, so I’d stick with the 30fps.  The dose/rate guess @25mSv/hr is good enough for starters, considering that could still be a low-ball number.  The dots per frame count; that was smart counting a quarter and extrapolating.  The dots per frame would vary considerable, but a snapshot count is good enough for starters.  

Agree we should try to get a reliable count for the reference part of the ratio; I’ll look for more tepco video showing dots with a Geiger count, maybe Chas or Cali have links handy.  The ISS recordings are no help because they don’t include a radiation reading.  

I hope differing frame rates don’t affect the ratio we’re trying to build.  

Reference count at 30 fps  ::   tepco count at a realized 5 fps

I picked a tepco count of 20 dots per hour because that’s when the emissions get thick and I use it as an indicator that something is steaming up.  Once we get a realistic reference for the ratio, plugging in tepco counts should be easy.  

I know you’re worried about the accuracy of the numbers and that’s good.  Would like to plug in some numbers and see if we’re getting realistic results.

[RodgerRoentgen]

(03-29-2016, 08:03 PM)Horse Wrote: The video of the interior of the reactor was probably taken with a better camera than the tepco feeds, so I’d stick with the 30fps.  The dose/rate guess @25mSv/hr is good enough for starters, considering that could still be a low-ball number.  The dots per frame count; that was smart counting a quarter and extrapolating.  The dots per frame would vary considerable, but a snapshot count is good enough for starters.  

While I follow your train of thought, we must also remember that the cameras inserted into the PCV have to be very small in size. The camera, a light source(s), sensor payloads and some minimal mechanical device(s) for crude movement, all must fit through pipes 1-3 inches in size. In this case, they are probably sacrificing some video quality here to get everything to fit through. I'm thinking we estimate a little less for the small cameras in tight places. lets at least assume around 24pfs to be cautious. We still have another frame rate consideration though... more on that below.

(03-29-2016, 08:03 PM)Horse Wrote: Agree we should try to get a reliable count for the reference part of the ratio; I’ll look for more tepco video showing dots with a Geiger count, maybe Chas or Cali have links handy.  The ISS recordings are no help because they don’t include a radiation reading.  

ok, here is a possible first candidate:
https://www.youtube.com/watch?v=b8iVhnp9vFk

This video is TORTURE, but it does have a displayed count as well as SOME gamma distortion artifacts. It's a horrible video though. We might be able to pull out a sliver of data from this one. In only a few sections of the video we get to see the count the packbot is detecting. I picked out the following times with displayed counts (quite HIGH)
1:54 --- .85 Sv/hr
2:22 --- .87 Sv/hr
2:43 --- .84 Sv/hr
4:54 --- (can't tell...)
18:35 -- (displayed on larger screen in background but out of focus)
19:22 -- .19.Sv/hr
Again, this video sucks, but we can take some frames around those times that show dots. We might have to extrapolate counts for the entire frame based on the dark portion(s) that we can count dots in. It'll be fuzzy, but theoretically more accurate than our previous calculations. As we find more data like this and keep normalizing and combining it, the overall accuracy should increase.

The first 5 minutes or so we could probably get some data from. The rest of the video isn't that helpful. Also, why the hell cant they just put the camera they are FILMING A LAPTOP with on a TRIPOD?!? ARGH!!

(03-29-2016, 08:03 PM)Horse Wrote: I hope differing frame rates don’t affect the ratio we’re trying to build.  

This will always be a factor, but at least on your end it should be constant and predictable. Whenever more data is added from existing videos that have known rates, we'll need to very carefully consider the frame rate on several levels. While a camera might achieve 30FPS recording, we are not actually watching what the camera is seeing. Through the various layers of software, hardware and firmware that makes a live webcam stream possible (or youtube), more and more image and time compression is introduced, and this destroys some of the data we are looking for. We can use some good logic to take what data remains and get close to the data that has become obscured.

I can get into some detail about the image compression but it'll be a somewhat lengthy explaination. I think I'll start another thread to reference that train of thought. What I'll try to express in more detail is that even though camera capture 30FPS, when we watch it on the stream we lose lots of data and get 10FPS. The same applys to video we get from youtube. These videos are generally compressed again when uploaded, and even the flash player displaying the video on your computer can apply some compression to smooth out videos. All this adds up crappier image quality and less frames per second. Really we want to kind of do what you did and step through every frame in one second and see how many unique images are present for any video used for data.

(03-29-2016, 08:03 PM)Horse Wrote: I know you’re worried about the accuracy of the numbers and that’s good.  Would like to plug in some numbers and see if we’re getting realistic results.

Well, I believe we should strive for being as accurate as possible. I see plenty of speculation on radiation related to fukushima with nothing to back it up. We will also be speculating, but at least we have SOMETHING based on real data to back up anything we calculate. Ultimately we will never have an accurate number to say X amount of distortion on cam Y = Z dose of radiation. There are too many variables for us to nail down. But don't give up hope, this is still a good exercise and can help get a better understanding of all of the technologies involved. We can still get close in our calculation though, but we will never be able to check our work by standing in front of U4 webcam with a geiger counter...

[Horse]

Roger, I see getting a good reference will be the biggest challenge.  The youtubes may not be the best for counting or maybe a better way to say it;  if we find a youtube with rad readings and dots we should find the original tepco vid for the best count of a frame.  Tepco's vid library is hard to see titles and some vid's of interest went 404 on me.  Most of the vid's I checked had no time reference, extra work to guess a frame rate/sec.  FYI, I recorded some of the suggested youtubes and noticed odd, inconsistent frame duplicates when stepping thru so they have a low frame rate and also the youtube compression make it hard to work with.  The best candidate would be a tepco video with dots that have a time counter and a rad reading associated with the vid.    


Some samples of dots:

youtube vids

(Full) Fukushima JP packbot investigation reactor 3 (roger wants to start with this one)
https://www.youtube.com/watch?v=b8iVhnp9vFk

Reactor 3 PCV equipment hatch investigation 9/9/2015  (pia posted spark sample)
https://www.youtube.com/watch?v=jzAdZFU8N_c

Inside Fukushima I Nuke Plant Reactor 2 Containment Vessel - Longer Version (1/4)
https://www.youtube.com/watch?v=aR--2dASoJA


Tepco vids  http://www.tepco.co.jp/en/news/library/a...atid=61793

2011.4.20 The videos were taken by the Packbot inside the nuclear reactor building of Fukushima Daiichi Nuclear Power Station - 1st Floor, Nuclear Reactor Building, Unit 1
http://www.tepco.co.jp/en/news/library/a...atid=61793

[Horse]

https://www.youtube.com/watch?v=b8iVhnp9vFk
might be

2012.11.28 Fukushima Daiichi Nuclear Power Station Unit 3 PCV equipment hatch rail (Video recorded by Packbot)
http://www.tepco.co.jp/en/news/library/a...atid=62055

2012.11.28 Fukushima Daiichi Nuclear Power Station Unit 3 PCV gas control system duct inspection (Video recorded by Packbot)
http://www.tepco.co.jp/en/news/library/a...atid=62055

search by date nov 2012
http://photo.tepco.co.jp/en/photo/2012/201211-e.html

I downloaded the two videos, got windows media files. Would be interesting to get a couple reference sources to check for consistency of the rad rate and dose to the amount of sparks. Ideally, a screen full of just a few sparks would make it easier to count.

[Chasaha]

I think I found the video I had mentioned in a previous post by YT user BioNerd.

[UPDATED] radioactivity on video - just like inside chernobyl
https://www.youtube.com/watch?v=jFNvYA7731o

see the americium at 3:00 minutes in  

[Horse]

(04-05-2016, 01:19 PM)Chasaha Wrote: I think I found the video I had mentioned in a previous post by YT user BioNerd.

[UPDATED] radioactivity on video - just like inside chernobyl
https://www.youtube.com/watch?v=jFNvYA7731o

see the americium at 3:00 minutes in  

Thanks ChasAha, I liked this one.  The americium storm looked like the videos inside of a reactor.  The one I think might be useful for counting purposes and to get a rough idea of the rad range the tepco sparks might be in is the Cs-137 sample 0.250 u Ci. 30.07 years.  I recorded the video, stepped thru the first 20 frames and saved grabs.  I see 0 to 5 sparks each frame, mean of 2.5, assuming 10 frames per sec, for 25 sparks per second.  On the tepcams I'm worried about 25 sparks per hour at 5 frames per sec.  It's only a rough estimate as I haven't had time to actually do counts yet. The other samples in the video might give us comparative measures to tighten the reference.

[RodgerRoentgen]

I think I've found some really good starting source videos. Thanks for your video suggestions Horse, they led me to 4 videos on the Tepco site that have rad readings on screen and high rates that permit counting per frame.

The videos are these four:
http://www.tepco.co.jp/en/news/library/a...d=jilpgxe6
Download link
http://tepco.webcdn.stream.ne.jp/www11/t...20_01j.zip

http://www.tepco.co.jp/en/news/library/a...d=o852v7u0
Download link
http://tepco.webcdn.stream.ne.jp/www11/t...20_02j.zip

http://www.tepco.co.jp/en/news/library/a...d=erg32ld4
Download link
http://tepco.webcdn.stream.ne.jp/www11/t...17_01j.zip

http://www.tepco.co.jp/en/news/library/a...id=il57o19
Download link
http://tepco.webcdn.stream.ne.jp/www11/t...13_01j.zip

I started with an initial analysis from one of these videos. I'm going to start a new thread to cover the video/frame analysis process. It became a little more complicated than I initially anticipated, but all of that should render better results. These will be great baseline videos to start with. Once we have good data sets from these videos, we can analyze other videos like those above to confirm or adjust our calculations. Thanks all for finding the videos we have so far!

Horse, to calculate rates from the recordings you have, we'll need to iron out a few more details. Let me try to get the analysis process documented first so analysis can start if others want to jump in. Then we'll refine the video data you have as best as we can. Once thats done, we can at least make a calculation based on my initial analysis. I've been working on some spreadsheets to do the work for us. More on that soon...

For now, could someone do a quick analysis of any of the above videos to figure out the actual frame rate. This was the process of stepping through and counting all frames in 1 second and subtracting the duplicated frames. For some reason I am unable to go frame by frame with my media player at the moment.

[Horse]

Oh, those frame rates throw us a curve.  All this discussion of frame rates led me to look at the tepco videos a little closer.  The tepco camera feeds before 2016 were 10 frames per second and sparks lasted just one frame, each unique frame being one tenth of a second.  Videos before 2016 had more information and detail than the Flowplayer introduced by Tepco, only on their website, at the start of 2016 when they stopped all the other feeds.  Flowplayer displays 10 frames per second as well but only 5 frames are unique and 5 frames are duplicates thus the sparks last for 2 frames now, one unique frame and one duplicate frame.  Seeing half as much detail as before, it’s not surprising that on average I now find half as many sparks as last year and the decrease in the changing pixilation even seems to make the emissions look less vigorous when viewing.

[Horse]

A video recreating sparks or dots on a camera using radioactive sources as is seen on the tepcams.  See ChasAha video by bionerd23.  

https://www.youtube.com/watch?v=jFNvYA7731o

The video test showed various sources, a, b, and g creating sparks on the ccd output.  CCD sensor was removed from protective coverings to allow unrestricted emissions detections.  Alpha was said to burn the pixel to a constant white output.  Sparks were said to be beta.  

The video was a good demonstration that radiation does affect ccd cameras.  Propose further testing of common ccd cameras for more specifics to determine a radiation level and conditions that mimic the tepcam spark activity.  

Suggest using unadulterated cameras to determine what penetrates normal lens or casings and what distance and radioactivity rate are required.  

If a spark is found to be A, B, or G; what then is the distortion that occurs during increased spark activity?  

From the videos I’ve seen, here’s my guess to test.  Alpha radiation would normally be blocked by a lens or a casing and ccd sensor damage would not normally occur.  Most likely it is Beta radiation which can penetrate up to a few inches of solid material causing the random dots to appear without damaging the camera sensors.  If not, we have Gamma radiation that can easily penetrate the camera.  Would Neutron radiation cause any visual effect on the sensors besides making the camera itself radioactive?  

RogerRoentgen has Geiger counters and radioactive material to test with.  I supplied a usb camera with software to record the experiments.  

The first test with an unmodified usb camera and various radioactive sources up to 7700cpm did not produce any sparks.  

More testing is being planned.  We don’t have stronger radioactive sources to test with so we’ll try removing the camera’s protective lens and expose the ccd sensors closer to the sources.

[RodgerRoentgen]

(04-15-2016, 06:54 AM)Horse Wrote: Oh, those frame rates throw us a curve.  All this discussion of frame rates led me to look at the tepco videos a little closer.  The tepco camera feeds before 2016 were 10 frames per second and sparks lasted just one frame, each unique frame being one tenth of a second.  Videos before 2016 had more information and detail than the Flowplayer introduced by Tepco, only on their website, at the start of 2016 when they stopped all the other feeds.  Flowplayer displays 10 frames per second as well but only 5 frames are unique and 5 frames are duplicates thus the sparks last for 2 frames now, one unique frame and one duplicate frame.  Seeing half as much detail as before, it’s not surprising that on average I now find half as many sparks as last year and the decrease in the changing pixilation even seems to make the emissions look less vigorous when viewing.

Great Horse, this will be used in the calculation. I'd say based on your analysis, we can assume 10fps when the tepco cams were ASX streams (pre Oct 2015) and 5fps with flowplayer (after oct 2015). Yes, we are losing data in the dropped frames, but we should still be able to establish the same ratio if it is 10 or 5pfs.

---

Analysis and calculated results

---

I'm spinning my wheels here on how best to simplify the process. I have a working system to make a calculation of dose based on counts from the tepco cams. The attached spreadsheet includes my initial analysis as a base set of numbers to work from.

  CamAnalysis-inProgress-a1.xls (Size: 19 KB / Downloads: 157)

What really needs work in this spreadsheet is to permit entering multiple sample data results to generate some sort of useable mean or average that is then used to make the final calculation. As you can see in the spreadsheet, section 1 & 2 were my original analysis, section 3 is the area for taking all of the sample data inputs and making a more average number to use in sections 4 and 5 for the final calculation.

Hopefully others can at least see what is going on in the calculating process. My goal is to come up with a CPM from the samples that is related to the video (sample) size (in pixels). the size factor is important so we can compare to the relative pixel size of the tepco webcam. the CPM rate is used in the calculation of dose in creating a ratio of CPM to pixel area over time.

Horse, you can try entering different values in the B57 cell. this cell is where you enter 'how many seconds between counts' (average). I did my best to fill in all of the information you've given me so far for the tepco cams (frame rate and CPMs). I determined viewing size (pixels) for tepco cams  and also provide a 'masking %' to subtract out the portion of a frame where you can't catch a dot. Those are the areas with high lighting, sides of the buildings and portions of the vent stacks and cranes. I've estimated this portion to be around 25% of the frame where counting a dot isn't possible.

Finally at the end, we see the calculated value of dose in the various sv/h units. This calculation factors in all of the video sizes, frame rates, time rates and masked areas to give as acurate a calculation as I can estimate. Remember all yellow cells are calculated values and red cells are for data entry. Not all calculated values are used in the final calculation, but were there to help me better nderstand the data. Maybe others can look over the spreadsheet and find better ways but for now this is the first in progress working model.

[Horse]

Quote:HillbillyHoundDog
August 18, 2017 at 10:11 pm · Reply
HORSE, https://www.youtube.com/watch?v=uYrhWO_ZLYw&t=0s

Mini reactor- Sparks, just the same. Interesting comments…

A controlled, water shielded reactor was still releasing nuclear elements emitting Gamma radiation measured next to the pool and showing as the Cherenkov radiation sparks detected by the camera sensor.  At 7:07 in sparks are mentioned as being gamma.  The comments included measured radiation readings at the time when sparks are blinking.   A 10 mR/hr reading during a small spark burst on the video to roughly calibrate the Gamma of the spark bursts I still find on the tepcams.  

Breazeale Nuclear Reactor Start up, 500kW, 1MW, and Shut Down (ANNOTATED)
Alex Landress

[piajensen]

That's fascinating. A functional reactor giving off sparks vs.the dysfunctional/broken Fukushima giving off sparks. I wonder how many hundreds or thousands of years Fukushima will continue to produce the reactions that you document.