Nuke

i think the thing they recover is actually silver. most of the actual gold is really just a thin plating on contacts to keep them from corroding. but some solders have as much as 15% silver by weight. there is also copper as well which is probibly also valuable and is most of the weight. the good news is all the heavy stuff is the valuable stuff. you could mechanically shred the boards, stick the shreds into a vacuum furnace (microwave heating) and accumulate the metals in a mold at the base, extract the ingots and sent them to a metal refinery to separate the valuable metals. the bad news is you can do the same thing with an old oil drum and some coal and a 3rd world workforce.

i managed to get my color compression to work, but its not as good as i had hoped. but it is pretty good when you consider than uncompressed 9-bit looks like this the sun is going to come up, so i need sleep. i still want to do a 12bit format with a 6bit delta to compare. i also think i will try a 12 bit format tomorrow. im thinking a 6x6x2 color table with 2 12-bit colors, which shouldnt be as hard, just change a few numbers on the 9-bit algorithm. that one will push the bpp up to 2.67 though, and i kind of want to go in the other direction. 8x8x2+12x2 will get me down to 2.375, but i dont know what that will do to my quality. i also want to try another grayscale algorithm, 8x8x2+8x2 will net me 2.25bpp. theoretically with a 2 bit index color the lowest you can get is 2bpp, so 2.25 sounds pretty good.

i finally figured out why i was getting horrendous blobking. i noticed that it was very rare for more than one color in each block to get utilized. the cause was pretty stupid actually. since my test code is written in lua there is no easy way to store pixel data. you could fill a table with numbers but that is very bad on memory usage. so i am storing my pixel data as strings where each pixel color is stored in 3 chars (im using 24 bit, mainly because i havent added 8 bit support to my code yet, after i load the image i have a function that scans through and averages out the 3 colors, then i only bother reading the blue pixel). since i need to convert the char to a number before i can operate on it, i have a call to string.byte() to convert it over. somewhere later on in the program i inadvertantly did the conversion a second time. since lua automatically does number to string conversion as needed, it didnt toss an error that my string wasnt a string. yay lua! i also noticed a couple other bugs in my algorithm. first of all the division by four in step 3 was wrong. because pixel zero in the color table is just an offset, i can only apply delta 3 more times so the full range wasnt utilized. i also threw in some floating point rounding in there to smooth things out. of course this breaks one of the assumptions i had made earlier whilst designing the algorithm, that say if you had pixels of value 0, and another one at 255, that it would be impossible to represent both values without a huge loss in brightness. since 3*63=189, i could loose up to 66 brightness levels in a block, which will make it stand out like a sore thumb. there are several ways to solve this problem. i could use a global scaler constant, so that a delta value of 1 actually represents a value of 1.35 (which would permit me to use the full range), though im concerned that might result in some quality loss or excessive overshoot in low range blocks. but generally shotgun approaches like that are bad, especially for such a rarely occurring problem. i could do big changes to the format, like do 6x6 blocks and 2 8-bit values, but that would change the data rate and i really want to make a 14 bit color info work. i can selectively detect when there is not enough delta range and center the range of the color table between the minimum and maximum values. this doesnt actually solve the problem, it just applys it more fairly to both low and high value pixels and might improve visual quality, but the decompressor wont care and will just decode it like every other block. i might consider the high values of delta "magic" and generate the color table slightly differently, say offset+index*delta+(22*index), when the delta is 63 (for deltas of 60-63 i can use constants 6,11,17,22, so that intermediat ranges between 189-255 can be better represented). also it turns out there is another problem, it is also possible to exceed the range of 255 if you have a high offset and when generating the color table it is possible to produce pixels that are higher than 255. rarely does this exceed it by very far, so a simple conditional is used to detect that. before i try to implement the changes above, i should point out that with the first bug fixed, images now look like this: look at that improvement in quality. not bad for 2.56 bits per pixel. if you zoom in you can see a few compression artifacts, but i am quite impressed with this block format. because of the quality im going to work on a new format rather than try to perfect this one. i am going to tackle color! i ran some numbers and i think im going to do a 7x5 pixel block with 2 bit indices and 18 bits of color data, each block will be 11 bytes. i can either do two 9 bit colors or i can do one 12 bit color and a 6 bit delta, so the next tests will be comparative analasys between the two. i should also point out that the data rate will be even smaller than the previous format @ 2.5143 bits per pixel. seems a general rule of thumb is larger block sizes let you trade quality for size, so it will be nice to see what this block will look like.

so a few days ago i was playing around with one of those esp8266 internet of things modules. its a nifty little gadget that lets you connect anything with uart to wifi. it got me thinking, what can i do with this fun little gadget. i played with moving strings between computers and my arduino. rummaging through my dev boards i found several camera and lcd modules i can play with and so decided to see what kind of images, possibly even video i can send over wifi. it has all kinds of applications, remote rendering to portable devices, wireless cameras for drones and robots. there is one small catch, the maximum data rate is supposed to be around 2 megabit so i need compression. i cant just use something off the shelf or out of a library found on github. i need something that can compress fast and decode even faster. i will probibly be running it on an arm arduino. so im going to need to cook up some algorithms. time for some science! in fact i had spent the last 3 days working on the required tools to do some reserch, and around 1:30 am i smashed the last bug and was ready to start writing some algorithms to test. i drew a lot of inspiration from the way block compression algorithms for game textures work. you turn an image into a bunch of small cells, and use indexed color to reduce the bits per pixel. dxt1 uses 2-bit color indices, so each cell has only 4 colors. however it only needs to store 2 colors with the cell, the brightest and darkest presumably, and interpolates 2 more intermediate colors. its color data is 16 bit, and so 32 bits go to pixel indices, and the other 32 go to colors, so it only takes 4 bits per pixel. my first attempt was on a grayscale image. i know i can get better than 4bpp with gray. im using a 5x5 block, the reason is i needed an extra 6 bits. unlike dxt1 which uses floating point interpolation, my format only stores a single grayscale value. i also store a 6 bit delta value, so i can use simple addition, multiplication and bit shifts to do the arithmatic. this is a data map one of the blocks: --in binary the image would be in the format: (1 char = 1 bit) -- PpPpPpPp PpPpPpPp - pixels 0-7 -- PpPpPpPp PpPpPpPp - pixels 8-15 -- PpPpPpPp PpPpPpPp - pixels 16-23 -- PpDddddd Oooooooo - pixel 24, delta, offset -- total size: 64 bits, bits per pixel: 2.56 --compression algorithm - 1 determine the extents of the pixel values in the block, these are valueMax and valueMin - 2 valueRange will be calculated as valueMax-valueMin - 3 the delta will be calculated as follows: valueRange/4 (the division can be performed with a right shift by 2 for speed if neccisary, otherwise a fixed point divide will be used for better rounding) - 4 the offset will be valueMin, it may be adjusted to compensate for any overshoot or undershoot of offset+delta*3 in relation to offset+valueRange - 5 the color table will be build such that color indices 0-3 will equal offset+index*delta - 6 the uncompressed pixels will be given the index of the color value in the color table that it is closest too - 7 the data is packed into a 64-bit block as shown above - 8 to decompress, the color table will be generated as in step 5, then each pixel will be assigned the value that corasponds with its index. decompress should be very fast. if you have a pocket calculator, you can divide the number of bits by the number of pixels to get the bpp: 2.56 bpp! a frame @ 640x480 will only be 96k. 10 fps should come in at under a megabyte. though there is a tiny problem in that an arduino only has 96k of ram total, and that would take 8 megabit to move over the esp8266. so i will probibly have to decrease the resolution to make it usable. at 320*240 is more usable at 24k a frame. so what are we looking at in image quality: its not quite optimal, there is a lot of underuse of the color table, only about 1/10 blocks has more than one color used. so it needs some work. but in my eyes its a succes, im on the right track. now i require sleep. tomorrow i will attempt a color format.

a lot of scifi universes like to use feudal systems or a confederacy for multi-planetary governments that span many star systems, since you really cant have any kind of centralized government. for example your vote for a presidential candidate might not arrive until that presidents term is up. this would make operating a centralized democracy impossible. any planet/solar system can have whatever kind of government(s) they want but then have alliances and treaties with other nearby planets/solar systems. for a colonized solar system i have a feeling governments wouldn't be to different from the multinationalism we have today. distances of communication/travel are long but managabe. either way i can only imagine running a government would get much more complicated than it is now.

currently working on algorithms to see if i can send compressed grayscale video through an esp8266 wifi-uart bridge, totally relevant to indoor droning. i have an idea for an algorithm that can get lower than 3 bits per pixel data rate without too much quality loss, looking at about 5 fps if my arduino can compress the data fast enough. i mostly coded test apps in lua today to read image files and functions to manipulate the data so i can get before and after images of the compression "quality".

learn 2 grill. i hate it when people overcook their meat.

i want a ribeye steak, bout an inch thick, and i want it rare.

it says im snarky enough to have a few dots yet not quite good enough to have a full bar.

i was just playing around with one of those esp8266 boards. its pretty nifty. i was able to get it on my network in a single evening and got it talking to a lua script on another rig. it also only takes 5 connections to my arduino due (if you run a 3.3v board, 5v needs level conversion). it also has a very simple at command set over serial, so you dont need any libraries to use it. supposedly you can run the thing stand alone though the mcu on the module doesnt have a whole lot of i/o. anyone using these things yet? did we ever get an over ip version of this interface?

most expensive pizza delivery ever. i hope the iss crew likes anchovies.

mint is nice

you can race, but most people dont. i mean if you kill all the other cars then there is nothing to race against and you kind of win be default.

interstate '76 <3 carmageddon as well. sometimes i wish they would breed and have an abominable mutant offspring. it would mix the car dogfighting with the pedestrian splatter demolition derby of carmageddon. i didnt really like games like twisted metal, it felt too arcadey. carmageddon had a somewhat interesting physics model with deformable geometry on the cars. it wasnt just the carnage in that game that made it awesome. interstate '76 ran on the mechwarrior 2 engine which likely explains why i enjoyed the game so much. dogfighting in cars is kind of tricky, the guns were fixed and so if you needed to shoot down a helicopter, you had to find a hill. you could get turreted weapons and missiles but that wasnt as fun. you also had a pistol for shooting out through the side windows. i always wished i could do that in carmageddon, because sheep.

while i do prefer coke over pepsi, what i actually drink is the generic knockoff of both.

i saw a ufo when i was 5 and living in the california desert. it looked a lot like an f117 (which were still classified at the time).

yea l liked the dc-x/i. it doesn't try to do anything exotic, its just a really big rocket that can fly back.

humans are already one of the most deadly species on the planet (right behind mosquitoes) and you want to make it deadlier.

honestly i only read this thread in case eagleworks or whoever posts news and the thread explodes.

i just junked a rig like that, stripped it of useful parts, chucked the mobo in the scrap pcb box and the case in the dumpster. useful drives got put in another machine. theres also an old cd rom i figure i can salvage the stepper motor for some project. the psu will make a good bench supply. id use it as a linux box. find a lightweight distro to play around with. windows can make old hardware seem slow.

people had peen pressuring me to make fried chicken for awhile. i always put it off, and the rising cost of chicken didnt help much. one day they bring me a whole frier chicken and everything else i needed was already in the pantry. nailed it on the first try. i guess the trick is to not be afraid of so much oil, if you dont put enough down the food wont float and it will stick to the bottom. same rules apply to chicken fried steak, but because they are usually thin you dont need as much oil. i also reuse my fry oil 3 or 4 times before throwing it out. i can also do a lot of things with a deep frier. onion rings, corn fritters, apple fritters, donuts, beer battered halibut, shrimp tempura, and so on.

neither, jailbreak it and instal linux proper.

idk whats my name here...ah yes. when i was very little i saw a documentry on nuclear weapons. i always found them quite awesome, mankind greatest accomplishment (i even thought that before i knew you could use them as rocket fuel). so i named my self after them.

i once made what i called "admiral lucifer's chicken". my own version of general to's chicken. needless to say it was way too spicy, and totally awesome. i didnt have any of those little red chinese peppers, so i substituted them with habaneros.

many things. i could probibly figure out anything with an unlimited grocery budget. unfortunately limited budget doesn't allow for what i like to call "science experiments", so i stick to things i know how to make without messing up.