If we look at the example of the FFT blur filter, sure O(n) looks easier and independent of the blur size, but you have an overhead in needing FFT and iFFT. It can be faster for some sigmas, but not for all. So you need different variants depending on sigma and a smooth transition between them.
Then you can start approximating - for large sigmas just using every 10th pixel would work. Looks like MS Teams background blur is doing this, you get a blurry background with aliasing - yay!
Once you add SIMD variants and look at CPU caching behaviour, you build versions for different CPUs. Instead of filtering the whole image for one dimension you might finish blocks locally.
You've now got a dozen variants that need testing and maintenance on different architectures.
I'm reminded of my colleague preaching requirements engineering - what was the goal gain?
Well.. it sounds like they want to "avoid bulky VR headsets"
But their alternative is even bulkier. A chair with a big screen, more like a personal holodeck box to sit in.
I totally believe this can be used to place better optics and avoid motion sickness, for better immersion.
The product vision is not clear for me - maybe as a better version of the single person privacy phone booths that can be found in shared office environments? At home? Rather not
I actually laughed out loud when I reached the end of the article decrying "bulky" headsets and finally saw their alternative. Reminds me of the giant egg thing that Darth Vader lives in.
The capacitor circuit has the advantage that could can't mis-drive. If a transistor of the half bridge stays turned on for longer than the msec required, nothing will happen. The half bridge chip (usually) already prevents that both transistors are enabled at the same time. This is great when you develop firmware and might end up with one pin staying high for too long.
With a direct drive, the flip dort magnet wire could quickly burn through if you leave half an amp for too long.
This is how the gas valve driver in your heating boiler works - there's no way anything can actually cause the valve to stick on because it's driven through a capacitor. The microcontroller pulses the valve signal at a few Hz, and it effectively works like a charge pump.
If the output sticks low, no biggie, it's low, the valve is off.
If the output sticks high, no biggie, the drive capacitor will charge in a second or so and pass no more current to the pump capacitor, which will discharge and shut the valve.
> With a direct drive, the flip dort magnet wire could quickly burn through if you leave half an amp for too long.
Quite often you see solenoid drivers that avoid that with PWM. The airbag driver pack in my old Range Rover does this, as did the Hydractive suspension controller in my old Citroën. In the Citroën the microcontroller directly drove a Darlingon transistor to turn the solenoid on to open valves in the "cross feed" pipes in the suspension. Because that needs to switch quickly against a high pressure hydraulic feed, it needs a lot of current, but because "soft mode" with the valves open is the normal mode for the suspension with the solenoid energised you couldn't leave that current on for a long time.
So what it did was it pulsed the solenoid on for about 250ms and then pulsed it at 50Hz or so, audible as a faint buzz under the car somewhere when everything else was off and clearly audible at certain frequencies on Long Wave radio while driving - very useful for diagnostics! You'd hear the buzz drop out and come back as it switched from soft to hard mode when you threw it around corners.
Similarly the airbag driver module for the Range Rover uses six bloody great big MOSFETs driven by a surprisingly complex analogue circuit with an opamp and a couple of transistors to pulse the solenoid on for 100ms or so and then pulse it at 30% duty cycle at some high frequency.
The valves are held closed by air pressure so they need that initial whack of current to open them, but then they can be held by far less current - well, 30% of the normal current, I guess - once the return spring and air pressure has been overcome.
This is the first time I've seen this mechanism described! I had to reverse engineer my oven control board because the transistor in this scheme died and after staring at the capacitor and diode for a minute it finally clicked, metaphorically, and literally, after I changed that transistor.
True, but you can program a controller such that this condition does not happen (modern microcontrollers have watchdog timers).
A bigger advantage of the capacitor approach is that you save power (though you could handle that centrally).
A downside of the capacitor approach is that capacitors can slowly leak, but for the application that does not matter much, I suppose. It just has to look nice.
I'm puzzled as there seems to be a clear pattern on how a human user would look like vs a bot.
High bot likely hood if: If a session jumps to a different ip. If the session jumps IP after just a few requests. If a new blank session starts with a deep link. Maybe those are cases where some POW is better justified?
Assumption: the rendered HTML might be viewed by a legitimate developer, even via a deep link from outside. But rarely from a wget script without a session cookie .
The other nice idea from the comments - is this rendering effort something that can be pushed to the user? Instead of pointless POW work, can you offload the expensive rendering to the user side?
But certainly, this is just an armchair comment and the kernel guys certainly have tried everything in this arms race...
This hints at a hiking trip planner maybe?
Depending on time of day and year evaluate a path to be in the direct sun/shade?
In summer, I might want to avoid the direct sun. Suggest the hiking path with least direct sunshine. And if it is autumn already, then please suggest a hiking path to be in the sun all day.
Might be a cool feature to compare hiking paths by percentage of direct sunshine.
But maybe, selecting a path through a forest vs. across open fields might already do.
Great result - it would be nice to learn how this could be used..
How would you connect a Tamron lens to a Linux machine? Is this with the external USB port or Bluetooth dongle? Or through the bayonet connector? A linx camera controlling it's lens?
Just for settings and firmware update? Or some imaging workflow? Can you give a practical example of Linux also controlling the camera?
New Tamron lenses have built-in usb-c port close to the lens mount. The utility just replicates what official Windows/Mac software does - not much, configuration of focus-by-wire, corrections, button functions.
Modern lenses are complex electronics now. They need to communicate with the camera about correction params, metadata, control algorithm for focusing and stabilization. Having a usbc port is a natural next step.
Lenses have energy budgets, responsiveness concerns and actuator/sensor pairings through embedded processing. Therefore they need firmware. Firmware goes out of date and has bugs and improvements. Having the ability to configure a lens beyond simply selecting firmware is an obvious second use of the required interface.
Firmware doesn't inherently have more bugs than hardware, in general that's a consequence of the ability to update it more than the other way around. Here the need for an update-able firmware comes more from implementation a reverse engineered interface which might need fixes for compatibility with future cameras or updated camera firmware that only care about official vendor approved lenses (which consequently don't have a need for an update interface). However that still doesn't explain who would want things like auto-focus fine tuning or assignable buttons in the lens rather than the camera body where it already exists. Just because the USB interface is there doesn't mean that this use of it is useful.
> However that still doesn't explain who would want things like auto-focus fine tuning or assignable buttons in the lens rather than the camera body where it already exists.
1) not all camera bodies include those fine tuning options in the camera firmware;
2) lenses that include additional buttons beyond that which the camera maker programmed the body to understand can't be tweaked by a body that was never programmed to know the button exists;
3) in the specific case of some Tamron zooms, the Tamron focus fine tuning is at up to five different distance figures, while most camera body focus fine tuning is a single global setting for that one lens;
4) for camera bodies that do include focus tuning in their firmware, they also usually have a limited number of slots for a limited number of lenses. For professionals they very well may own more lenses than the camera has slots, so being able to "tune the lens" via "the lens itself" means each can be fine tuned, even if the camera body cannot store that many different adjustments;
5) an adjustment the camera maker never thought to include (i.e., one example quoted in the repo where the focus ring direction can be reversed) can not be tweaked by the camera body. This is useful to photographers who mix lenses from different makers on the same body as Canon builds their focus rings to rotate one way when focusing towards infinity while Nikon builds their focus rings to rotate in the opposite direction towards infinity.
Modern DSLR camera lenses are full blown embedded computers controlling mechanical actuators (focus motor, aperture blades, etc.) and communicating lens information to the camera's CPU (aberration corrections, vignetting corrections, etc.). The days of lenses just being collections of mechanical cams for moving glass elements back and forth disappeared a great many years ago.
A hub motor for each leg adds some weight, but you get a rolling mode on flat terrain with great range.
At the same time you keep obstacle climbing mode with stationary wheels, and can use the leg actuators as shock absorbers and obstacle avoidance on a bumpy path. Best of both worlds, with a new software challenge.
Then you can start approximating - for large sigmas just using every 10th pixel would work. Looks like MS Teams background blur is doing this, you get a blurry background with aliasing - yay!
Once you add SIMD variants and look at CPU caching behaviour, you build versions for different CPUs. Instead of filtering the whole image for one dimension you might finish blocks locally.
You've now got a dozen variants that need testing and maintenance on different architectures.
I'm reminded of my colleague preaching requirements engineering - what was the goal gain?
reply