@Thanatomanic - these edits look great, thank you for taking the time to do them! It is much appreciated.
In markdown, double spaces at the end of a line add a hard line break (for the “main developers” and “main contributors” lines to be in the same paragraph but to retain a hard line break. I’m going through the rest of your patch now (thank you so much!).
Got a link by chance? Or maybe the man himself @Andy_Astbury1 could provide me one? I can tweet it via the RT twitter account as well, or even follow up a post immediately afterwards (or for other social output).
Speaking of social output, thanks for the recommendation @Zahtar - I’ll reach out to Roger Clark (would you happen to have contact info for him handy you can send me?).
I’m thinking we can publish either this weekend or wait until Monday. (I usually wait until Monday to not bury the news over the weekend, but this isn’t really “traditional” publishing in that sense and our audience, RT users, might like having the news to peruse with their free time on the weekend… ).
I’m doing a last look now and will try to push it out tomorrow morning (US Central time - UTC-0500).
Hello
This is “normal” because the “LA” process is after reconstruction.
It is explained how to solve this problem in the case of “Log Encoding”, but it is exactly the same for all processes that will touch the reconstructed areas
I know a lot of working commercial togs who shoot flat frames all the time in the studio and on location - and the come in handy for removing dust spots too!
Pushing was a royal PITA as I couldn’t connect via SFTP (or SSH) to the webhost.
I finally managed to get the site uploaded (but my local ISP is having issues at the moment and i couldn’t see it - I spent a good 15 minutes in a panic that I had broken the site…).
Thank you all for getting this post up! I’ll try to reach out to some places soon to spread the word (if anyone has ideas or accounts in other communities to let them know - please do!).
Has anybody compiled RT on an ARM processor such as a Raspberry Pi? I compiled it on a newish Samsung tablet inside Andronix and it seems to run well. Maybe I should get a Raspi and create a package or so… anyway I would think that darktable or vkdt would not run well on ARM hardware, so that only leaves RT and ART.
No, but I regularly build and run it on a PowerPC32 VM, which es even more special than ARM, because it’s big-endian and has an unsigned char type. RT is pretty portable.
I could give the non-answer: “a computer”. But in all honesty, I don’t know. Any lower margin seems very arbitrary to me. It depends heavily on the raw input (megapixels) and which modules you use.
In principle, any modern 64-bit computer with a half-decent CPU and some RAM could process most raw formats comfortably.
This is RT on Debian unstable RISC-V 64bit in QEMU. It took some time to get the VM ready and even some more to compile RT. But works as designed, albeit slow.
Nope but should work, even on older Pi hardware. Personally I’d recommend something like a 4GB Pi4, if only for the RAM. Image processing is usually RAM-intensive.
I do a huge amount of stuff with Pis at work, but it’s all headless.
Also Pis have become unobtainium lately.
In theory vkdt should be able to compile/run on Pis with fairly minimal work now that there is full Vulkan support on Pi 4. darktable would have issues likely due to OpenCL-on-Vulkan translation layers being, um… “meh” at best and Pi only supporting Vulkan and not OpenCL. Same problem darktable would have on the likes of NVidia Jetson - NVidia does not support OCL on their ARM platforms, so your choices are CUDA or Vulkan or an OpenCL-on-Vulkan translation layer. Every one I am aware of depends on clspv, which is limited to a subset of OpenCL 1.2.
).
