|
Early attempts at divining Carbon content of soil from sattelite remote sensing using ~mAtHS~ BASICALLY We are trying to get farmers to give a gently caress about climate change by creating processes for them to tap into that sweet sweet carbon credit eurobucks by sinking CO2 into the ground using various agricultural processes whilst minimizing the cost of instrumenting giant farms by taking photos of poo poo from space.  Next step , get out there with carbon probes and figure out if our machine learning models actually work. gently caress I love doing science. duck monster fucked around with this message at 12:52 on Dec 1, 2022 |
#
?
Dec 1, 2022 12:48
|
|
|
|
| # ? Apr 25, 2024 02:15 |
|
|
 I hate WebRTC, here are 16 devices streaming to a single desktop 🤷♀️ The small one is 4K, and the pillar and letterbox ones are 1920x1200, all others are 1080p. MrMoo fucked around with this message at 17:58 on Dec 23, 2022 |
|
#
?
Dec 23, 2022 16:14
|
|
|
I really like the retro look of terminal graphics and I wanted to see whether blitting terminal codes was fast enough for real-time applications. So I wrote an interactive Mandelbrot fractal explorer: The main trick is using a box drawing character and separate foreground/background colours to get square pixels in the terminal. It's probably a well known trick, but I was quite pleased when I figured it out. Performance is surprisingly good even when you increase the "resolution" by decreasing the font size, although obviously not nearly as good as with proper pixel blitting. Still, I'll probably continue using this technique to run visualisations on machines I can only access via text mode SSH. Code is here: https://git.sr.ht/~athas/tui-mandelbrot
|
|
#
?
Feb 9, 2023 10:26
|
|
|
Athas posted:I really like the retro look of terminal graphics and I wanted to see whether blitting terminal codes was fast enough for real-time applications. So I wrote an interactive Mandelbrot fractal explorer: Just use sixel
|
|
#
?
Feb 9, 2023 15:09
|
|
|
leper khan posted:Just use sixel That doesn't work in many terminal emulators. If I wanted to use something only pseudo-standard and not widely supported, I'd just use Kitty's graphics protocol, as it's much better than sixel.
|
|
#
?
Feb 9, 2023 18:53
|
|
|
Cory Parsnipson posted:so basically I'm just using this as an excuse to over engineer everything Sounds like how I do everything when I’m in project mode lol
|
|
#
?
Feb 13, 2023 14:48
|
|
|
Athas posted:That doesn't work in many terminal emulators. If I wanted to use something only pseudo-standard and not widely supported, I'd just use Kitty's graphics protocol, as it's much better than sixel. Pseudo-standard! I wish more stuff supported vt300 instead of vt100, Sixel and ReGIS are great for TUI.
|
|
#
?
Feb 13, 2023 19:07
|
|
|
I went crazy with multiple web technologies, an attempt at displaying synchronized content (images, video, 3d), across the interwebs. Kind of impressive how many web things can fail and fail well. WebRTC x Raft Consensus x WebSocket, and here showing Chrome x Edge x Firefox at 144fps with content sync at 10fps and renderer interpolation to full frame rate. https://www.youtube.com/watch?v=vvca0WYOCas Running Chrome x Chrome x Chrome is a lot better, 60fps normal iPhone cap: https://www.youtube.com/watch?v=shhIL3AtRL4 Then a 240fps iPhone cap: https://www.youtube.com/watch?v=YeXInmer-LA Which looks pretty much frame accurate on a 144Hz monitor 
MrMoo fucked around with this message at 02:55 on Feb 14, 2023 |
|
#
?
Feb 13, 2023 23:49
|
|
|
That's pretty cool. I did some sports broadcast systems work in the past and the way we'd get frame accuracy on a wire is to have a separate coax input for "genlock," which kept all the slow-mo, switchers, outputs on the same frame lock. I'm puzzled at how near frame accurate sync could happen over the web, but it looks clean! Is there some master clock pulse being sent? Even so, latency variance must throw this off by many frames randomly? It looks like a really neat thing to work on. e: I looked up the Raft Consensus algo you mentioned and printed out the paper for some light reading in the am. 
former glory fucked around with this message at 05:03 on Feb 14, 2023 |
|
#
?
Feb 14, 2023 05:01
|
|
|
Synchronisation always becomes a lot easier with the more latency you're willing to accept. What you've achieved is impressive! Is the content live? How much are you buffering?
|
|
#
?
Feb 14, 2023 11:52
|
|
|
I get reminded about genlock a lot, but this is the web and such integration is not available. Pretty much any broadcast quality video uses SDI and that's just not available on most hardware either. Live video is another problem, with insufficient research or funding over at least 2 decades, I don't have answers for that. Currently "cheating" by using MPV with low-latency configuration instead of the browser. The problem is generally that the clients have to follow the clock of the encoder, and to skip video to resync means audio jumping which humans are very much perceptible towards. Thus one usually has a choice between no-sync, some latency + audio, or no-audio, low-latency video. The majority of video players follow the clock signal in the video feed, but that assumes that the video player real-time clock is actually synchronised with the encoder clock. There will be drift, and it will accrue, and be incredibly obvious. The design decision in this implementation is reducing the processing required in the renderer. One conventionally thinks of clocks, as above, and this is correct for a video stream, however for a multi-media stream one has an abstraction and the clock is actually feeding a scheduler instead of the renderer. Thus if the encoder operates at the scheduler level and forwards the commands it would send to the renderer one yields less processing at the client, but larger transit payload. Consider how FPS network games operate, Doom 3, APEX, Valorant, etc. The game state is independent of the renderer and runs at a separate frequency. The viewable game state is forwarded to each client on each step. The client then extends that state with player-side prediction to scale up to the local display clock rate. Thus the state engine is running at 10Hz, _broadcasting_ at low latency to each client with viewable state, then the client interpolates to the local display frequency, here 144Hz.
|
|
#
?
Feb 14, 2023 12:34
|
|
|
I got bored and people were talking about KSP2s broken... everything so I decided to write a little N-body physics sim. It's kind of a boring shot, but without motion they all kinda are. The red color is just ones that are over an arbitrary limit I wanna use for star formation later. 
|
|
#
?
Feb 27, 2023 03:06
|
|
|
|
| # ? Apr 25, 2024 02:15 |
|
|
Recently restored "Gargantuan Takeout Rocket" which was broken for 4 months. It allows "Liftoff from Google Takeout into Azure Storage, repeatedly, very fast, like 1GB/s+ or 10 minutes total per takeout fast". I'm one of those people with a TB to transfer when backing up. So getting it quickly out every two months is very useful. https://github.com/nelsonjchen/gargantuan-takeout-rocket It's pretty fugly design, but in case the worst happens to my Google account or YouTube, at least I'll have a copy of everything. 
|
|
#
?
Feb 27, 2023 22:37
|
|