I think even after printing and scanning there could still be jpg artfacts from the original (e.g. if you scan lossless).
However, I wonder whether heavily compressing the redacted image would help remove any unwanted artefacts. But the best solution is probably to render the original file from scratch, without compression, before redacting the image.
Fabrice is an absolute legend. Most people would be content with just making QEMU, but this guy makes TinyC and FFmpeg and QuickJS and MicroQuickJS and a bunch of other huge projects.
I am envious that I will never anywhere near his level of productivity.
Not to detract from his status as a legend, but I think the kind of person that singlehandedly makes one of these projects is exactly the kind of person that would make the others.
I forgot about FFmpeg (thanks for the reminder), but my first thought was "yup that makes perfect sense".
I know it's not true, but it would be funny if Bellard had access to AI for 15 years (time-traveler, independent invention, classified researcher) and that was the cause of his superhuman producitvity.
And FFMPEG, the standard codec suite for Unix today. And Qemu, the core of KVM. Plus TCC, a great small compiler compared to C/Clang altough cparser has better C99 coverage. Oh, and some DVB transmitter reusing the MHZ radiation from a computer screen by tweaking the Vidtune values from X. It's similar to what Tempest for Eliza does.
I use Nextcloud for files/contacts/calendar/etc. as well, but for photos I use PhotopPrism [1].
The reason is simple: photos require much more processing and focus on performance. In addition, photos take up much more space, so while my Nextcloud instance runs on an SSD, the photos reside on an HDD, mostly in sleep mode.
I remember the first gentoo. On the framebuffer it had a beautiful blue/gray background with the logo and provided you with choices. You could build everything from scratch or install a bootstrapped version. I tried both, failed and gave up (my poor AMD k5 couldn't handle the heat). But the point here is: it was always easy to build a kernel within your debian installation from deb-src. You could even build it as a deb, install it and reboot into it. If my job was to manage a linux kernel, I'd have a script which took the latest sources, set kernel parameters, packaged it as deb-src and then it is just two steps to build and reboot. Then I could switch between them easily.
Same here. I also have an ente account, but only to check if they made relevant progress. So far, I don't understand why Ente has so much traction when PhotoPrism has the better feature set, in my opinion.
Actually, with a good architecture, SQLite brings you very far. However, you need a solid architecture; otherwise, the journey ends very soon. So people with architectural wisdom can build great things with SQLite.
The ones who warn about it are often the ones who don't care about architecture and just plug stuff together.
reply