Neal Wilson ✅ @neal@social.typica.us

Spent some time working on another new approach for generating measurements from the roaster cam. Results on some previously gathered test data look a lot better (25% error reduction, but I suspect I can push that farther by cranking up a parameter that I just didn't have enough data to push farther). I'll take my best guess at an implementation based on last night's exploration and work on getting a larger set of testing data for work on future refinements.

Their mascot is a reasonably cool looking fish.

The credit union just sent me an email about what I think is a sports team branded debit card that I could get, but it has no mention of which sport that team plays and I don't have prior knowledge of the team, so I guess I'm not in the target demographic for that product.

Also, has anybody ever made a histogram of which decks get hull breaches? On which decks are you most and least likely to get blown out into space?

Why do Starfleet people not break out the swords when they're engaging the borg? They know the phasers are going to stop working.

In normal times, the fire extinguisher maintenance people just come on a schedule, do their thing, and let me know if something more expensive than usual is coming up or required. If they don't show up and we don't have a fire requiring an extinguisher, the only people double checking that are the fire inspectors.

According to the fire inspectors, everybody has fire extinguishers that haven't been checked because the companies that do that have stopped and they're not marking it as violations for anybody. While our many fire extinguishers probably do still work just fine, please no arson.

Ordered Christmas mugs. One of the less overtly Christmas ones on the order is a sloth wearing a festive scarf.

The cat is expressing concern because I'm cooking dinner instead of hugging the cat.

I have an initial set of test images to work with now. Sadly, the information I wanted in the file names is not what got put there (the original code was placed after the relevant variable had been re-used for something less useful and I failed to notice that when adapting it). It's not a big deal because I can just replicate the code and have it load data from a file instead of from a camera, but it's more work to get started on the analysis than I hoped.

morning cat

If you can hear thunder, you are close enough to have already been struck by lightning.

From there, I can see if there's an easy way to automatically classify the images that perform well (I have some thoughts on this, but I need a data set to test those ideas against) and see if there's anything reliable in worse performing images where maybe a different approach to calculating the measurement might produce a better quality measurement.

The idea here is that 10 frames from each of several batches should be representative of the different image characteristics the system encounters and if I save those just before the end of the batch I can see how different types of images compare to the expected value as produced by a bench top analyzer. The expected values for those 10 frames should be very close to each other and to the post-roast measurement.

Today's code modification to the roaster cam is changing the behavior of the debug save button. Previously this created three images based on the next frame captured: the original image, the mask calculated for that image, and the masked image. Part of the file name is also what the system calculated as a degree of roast for that frame. I've changed this to do that for the next 10 frames, sticking each batch into its own directory.

Figured out my next avenue of attack for the problem I've been working on. Once I figure it out it's probably worth writing up a paper that like 3 people would read.

A sample size of one roast isn't enough to say anything useful, but it looks like the new code isn't worse than the old code, but is not as much of an improvement as I was hoping for. There's a parameter I can tweak before tomorrow's roasting to see if that helps, but I might need to investigate a different approach.

An initial test of just holding stuff up in front of the camera shows that it takes my code a little longer to settle on a value (as expected), but it's settling on the same value as the old code, so I'm tempted to have the system output the new values and see how that looks in Typica with a real batch.

Patched in a first attempt at what I hope will fix the issue I've been working on with the new instrument. For now I've got the display showing the results of both the old and the new calculations so I can see how those compare, but I didn't put any rounding on my approach so it's showing a way more than what's significant number of digits after the decimal point.

Who's a good cat?