tensorrt_demos VS grim

tensorrt_demo github repository

https://github.com/NVIDIA-AI-IOT/torch2trt <- pretty straightforward https://github.com/jkjung-avt/tensorrt_demos <- this helped me a lot

> I'll also add a caveat that toolage for Jetson boards is extremely incomplete.

A hundred times this. I was about to write another rant here but I already did that[0] a while ago, so I'll save my breath this time. :)

Another fun fact regarding toolage: Today I discovered that many USB cameras work poorly on Jetsons (at least when using OpenCV), probably due to different drivers and/or the fact that OpenCV doesn't support ARM64 as well as it does x86_64. :(

> They supply you with a bunch of sorely outdated models for TensorRT like Inceptionv3 and SSD-MobileNetv2 and VGG-16.

They supply you with such models? That's news to me. AFAIK converting something like SSD-MobileNetv2 from TensorFlow to TensorRT still requires substantial manual work and magic, as this code[1] attests to. There are countless (countless!) posts on the Nvidia forums by people complaining that they're not able to convert their models.

[0]: https://news.ycombinator.com/item?id=26004235

[1]: https://github.com/jkjung-avt/tensorrt_demos/blob/master/ssd... (In fact, this is the only piece of code I've found on the entire internet that managed to successfully convert my SSD-MobileNetV2.)

It was some work getting compiled on nano but I used this guy's work to get started. https://jkjung-avt.github.io/tensorrt-yolov4/ and https://github.com/jkjung-avt/tensorrt_demos

"GNOME doesn't support wlr-screencopy-unstable-v1, which is the protocol grim uses to take screenshots." Source.

It's in the README

there is grim which is supposed to work under Wayland but it seems like it only works under swayWM, the reason why i need a cli tool is that I want to build Rofi script on top of it, I'm a ware spectacle and it is a very great option but I would prefer a Rofi based tool .

sway laptop user here (for almost 2 years I think?).

I spent a little while on this, but I migrated from i3, so I just ported every little section of my config bit by bit.

In terms of battery bar and other "bar" type things, I use waybar[0] which basically does all the things you'd expect by default (just install and it "works").

For multi-monitor, config, I initially setup with wdisplays[1] (think arandr for wayland) and then manually copied the positions into my sway config. Monitor positioning was the only thing I needed to setup (and telling it that one monitor was HDPI) and then all of the scaling and everything worked perfectly. This was my biggest selling point for wayland, I now get nice crisp fonts and application scaling works nicely (which was not the case with X).

volume control from the keyboard took no time, just a couple of extra lines.

There was some stuff to do with the clipboard (wl-clipboard[2]) and screenshots (grim[3] + slurp[4]) that required some setup, but again, just a few lines, and didn't take much mental load.

Oh and I needed to change my notifications daemon(dunst[5]), and chose to change my program launcher to one with a nicer interface and cleaner fonts (wofi[6]).

I think that's all the tweaking that I did. Oh, and I needed to do something with pipewire to sort out screensharing at the start, don't remember that too well though...

[0] https://github.com/Alexays/Waybar

[1] https://github.com/artizirk/wdisplays

[2] https://github.com/bugaevc/wl-clipboard

[3] https://github.com/emersion/grim

[4] https://github.com/emersion/slurp

[5] https://github.com/dunst-project/dunst

[6] https://hg.sr.ht/~scoopta/wofi

grim might work well but you'll probably have to write a shell script or something to keep track of the user preferences. You'll also need slurp if you want to select a region to screenshot.

Screenshots: grim + slurp + swappy

Since you have already noticed that it does not work with Wayland, it is a strange requirement to take a screenshot "with it". Why not use a tool that does work with wayland, e.g. Grim?

# Details I'm an English speaker living abroad, and while I'm trying to learn the local language it's real hard. I found myself popping open a browser to use deepl quite frequently, or trying to find translator plugins for several different applications. To make this process easier, I wrote a script (bound to a hotkey) which will screenshot a selected area, OCR it, translate it to english, and show a notification with the translated text. It also copies the translated text to the clipboard. Why screenshot + OCR rather than just selecting and copying text? Images and screen-sharing, mostly. I think this is just a really cool way to show how the hard parts have usually been done for you, and all you need to do is put the blocks together. ## Implementation I'm running sway, so the several of the tools are Wayland specific. You could easily swap them out for xorg compatible variants if you like. The script is [here](https://github.com/rbuchberger/dotfiles/blob/master/scripts/screenshot\_translate). The toolchain is: * [Slurp](https://github.com/emersion/slurp) - select an area * [Grim](https://github.com/emersion/grim) - screenshot that area * [Tesseract](https://github.com/tesseract-ocr/tesseract) - OCR * [Translate Shell](https://www.soimort.org/translate-shell/) - Translation CLI * [Mako](https://github.com/emersion/mako) - Notification window Mako needed a little configuration to show long form text: [category=translation] width=900 height=1200 Edit: added details and links for the tools used.

I don't wanna poop on their parade, but haven't Wayland screenshotters been around for a while? https://github.com/emersion/grim

That one has at least been around for long enough, and has worked perfectly under Sway for long enough, that I had to look up its name because I had it bound to a hotkey and had forgotten what it was called.