> why not put a whole bunch of filters in front of a mono camera and get much more frequency information?
Just rgb filters aren't really going to get you anything better than a bayer matrix for the same exposure time, and most subjects on earth are moving too much to do separate exposures for 3 filters.
The benefits of a mono camera and rgb filters is that you can take advantage of another quirk of our perception; we are more sensitive to intensity than color. Because of this, it's possible to get a limited amount of exposure time with the rgb filters, and use a 4th "luminance" filter for the majority of the time. During processing you can combine your rgb images, convert that to HSI and replace the I channel with your luminance image. Because the L filter doesn't block much light it's faster at getting signal, but it's only really a benefit for really dark stuff where getting enough signal is an issue.
For the vast majority of things in the sky, they'd see black. This stuff is incredibly dark, and we need hours of exposure time to get enough signal. Even after hours of exposure the raw stacked frame is a black field with some pinpoints of lights.
The exception to this is stuff in our own solar system.
The problem is that the noise can swamp the signal. Another example of this would be doing astrophotography during the day. The sun doesn't block anything, it just makes the sky glow with "noise". Theoretically it has exactly as much signal from space as it does at night, but because the sun adds so much noise it's completely lost.
I don't remember exactly what I did, but I do remember running into that kind of problem. I probably used starnet2 to remove stars before doing much processing, and recombining stars towards the end.
I've seen some pretty impressive stuff done with a relatively cheap / simple DSLR setup.
The basics of astrophotography aren't that expensive, but it gets exponentially more expensive to meaningfully "zoom in". Because DSLRs with typical lenses are pretty zoomed out you can get away with much cheaper gear. You might look into getting a "star tracker". It's like a telescope mount for a camera; it'll keep the still relative to the stars but because they don't need to be as accurate they're far cheaper to make. They'll probably work just fine for your 200mm 2.8 lens for a fraction of the cost of a mount.
Haha, yeah. I could go on for hours. I've had to learn that most people really don't want a lecture series on the finer points of astrophotography. Seabass's comment was pretty much perfect; a bit of detail, but not so much to get lost in the detail.
I tried to write a quick comment on my process a couple of times before they posted, and each time I had way too many words on a small detail.
It's a wonderful niche/technical hobby, but it's not cheap. You could even say it's "pay to win". I didn't buy all of my stuff at once, and I had some mistakes, but I'd guess I use on the order of $10k in equipment.
Thanks! I hadn't gotten to writing this out, but you've pretty much nailed it.
> They most likely used a secondary camera whose sole purpose is to guide the mount and keep it pointed at the target object.
I did use a guide camera with an off-axis guider, I'm not sure why it wasn't in the equipment list. I've added it.
> The RGB filters were presumably for the star colors and to incorporate the blue from Alnitak into the image.
This is primarily an RGB image, so the RGB filters were used for more than the star colors. This is a proper true color image. I could get away with doing that from my location because this target is so bright. The HA filter was used as a luminance/detail layer. That gave me a bunch of detail that my local light pollution would hide, and let me pick up on that really wispy stuff in the upper right :)
> The processing here was really tasteful in my opinion.
For a little bit of context for how impressive this is, here's my take on it with a consumer grade 8" Newtonian telescope from my backyard: https://www.astrobin.com/full/w4tjwt/0/
I've been using terraform for 10-ish years, and this is very much not how I feel about it. Terraform absolutely makes life easier; I've managed infrastructure without it and it's a nightmare.
Yes, it can be awkward, and yes the S3 bucket resource change was pretty bad, but overall its operating model (resources that move between states) is extremely powerful. The vast majority of "terraform" issues I've had have actually been issues with how something in AWS works or an attempt to use it for something that doesn't map well to resources with state. If an engineer at AWS makes a bone-headed decision about how something works then there isn't much the terraform folks can do to correct it.
I've actually been pretty frustrated trying to talk about terraform with people who don't "get it". They complain about the statefile without understanding how powerful it is. They complain about how it isn't truly cross-platform because you can't use the same code to launch an app in aws and gcp. They complain about the lack of first-party (aws) support. They complain about how hard it is to use without having tried to manually do what it does. Maybe you do "get it", and have a different idea of what terraform should do. Could you give a specific example (besides the s3 resource change) where it fails?
It's a complicated tool because the problem it's trying to solve is complicated. Maybe another tool can replace it, and maybe someone should make that tool because of this license change, but terraform does the thing it intends to do pretty well.
It all depends on the properties of the signal and the noise. In photography you can combine multiple noisy images to increase the signal to noise ratio. This works because the signal increases O(N) with the number of images but the noise only increases O(sqrt(N)). The result is that while both signal and noise are increasing, the signal is increasing faster.
I have no idea if this idea could be used for AI detection, but it is possible to combine 2 noisy signals and get better SNR.
I think this is a really important comment, and until about 6mo ago I would have completely agreed with you. I even made these same arguments with my coworkers; it's just cooperative multithreading, it's making up for a defect in js, just use threading primitives. I think some people might use async in a fad-y way when they don't need to, or don't understand what it really is and think of it as an alternative to multithreading. You've generated a lot of good discussion, but maybe having a specific example of where async/await made writing a multithreaded process easier will help.
What changed my mind was accidentally making a (shitty/incomplete) async system while implementing a program "The Right Way" using threads and synchronization primitives. The program is for controlling an amateur telescope with a lot of equipment that could change states at any moment with a complex set of responses to those changes depending on what exactly the program is trying to accomplish at the time. Oof, that was a confusing sentence. Let's try again; The telescope has equipment like a camera, mount, guide scope, and focuser that all periodically report back to the computer. The camera might say "here's an image" after an exposure is finished, the mount might say "now we're pointing at this celestial coordinate", the focuser might say "the air temperature is now X", and the guide scope might say "We've had an error in tracking". Those pieces of equipment might say those things in response to a command, or on a fixed period, or just because it feels like it.
Controlling a telescope can be described as a set of operations. Some operations are fairly small and well contained, like taking a single long exposure. Some operations are composed of other operations, like taking a sequence of long exposures. Some operations are more like watchdogs that monitor how things are going and issue corrections or modify current operations. When taking a sequence of long exposures the program would need to issue commands to the telescope depending on which of those messages it receives from the telescope or the user; If the tracking error is too high (or the user hits a "cancel" button) we might want to cancel the current exposure. If the air temperature has changed too much we might want to refocus after the currently running exposure is finished. If the telescope moves to a new celestial coordinate we probably want to cancel the exposure sequence entirely. So, how do we manage all that state?
The way I solved it was to make a set of channels to push state changes from the telescope or user. Each active operation would be split into multiple methods for each stage of that operation, and they would return an object that held the current progress and what it needed to wait on before we could move onto the next stage. That next stage would be triggered by a controlling central method that listened for all possible state changes (including user input) and dispatch to the next appropriate method for any of the operations currently running. To make things a little simpler I made a common interface for that object that let the controlling central method know what to wait on and what to call next. This allowed me the most control over how different concurrent operations were running while staying completely thread-safe. It was great, I could even listen to multiple channels at the same time when multiple operations were happening concurrently.
At this point I realized I'd accidentally made an async system. The central controlling method is the async runtime. The common interface is a Future (in rust, or Promise in js, or Task in C#). Splitting an operation into multiple methods that all return a Future is the "await" keyword. Once I accepted my async/await future, operations that were previously split across multiple methods with custom data structures to record all of the intermediate stages evaporated and became much more clear.
I'm still using multiple threads for the problems that benefit from parallel computation, but making use of the async system in rust has made implementing new operations much easier.
In a language like C that isn't really possible because the language can't keep track of all of the places that memory address is stored.
If malloc were to return something like an address that holds the address of memory allocated there is nothing preventing the program from reading that address, doing math on it, and storing it somewhere else.
Amateur astrophotographer here. What I'm going to talk about is true for my rig. The JWST is astronomically a better telescope than what I have, but the same basic principles apply.
The cameras used here are more than 8 bit cameras, so there has to be some way to map the higher bit-depth color channels to 8 bits for publishing. The term for the pixel values coming off the camera is ADU. For an 8 bit camera, the ADU range is 0-255. For 16bit cameras (like what mine outputs) is 0-65536. That's not really what stretching is about though.
A lot of time, the signal for the nebula in an image might be in the 1k-2k range (for a 16bit camera), and the stars will be in the 30k to 65k range. If you were to compress the pixel values to an 8 bit range linearly (ie, 0 adu = 0 pixel, 65536 adu = 255) you're missing out on a ton of detail in the 1k-2k range of the nebula. If you were to say 'ok, let's have 1k adu = 0 in the final image, and 2k adu = 255', then you might be able to see some of the detail, but a lot of the frame will be clipped to white which is kind of awful. That would be a linear remapping of ADU to pixel values.
The solution is to use a power rule (aka, apply an exponent to the ADU, aka create a non-linear stretch). (EDIT: The specific math is probably wrong here) That way you can compress the high adu values where large differences in ADU aren't very interesting, and stretch the low-adu values that have all the visually interesting signal. In the software this is done via a histogram tool that has three sliders; one to set the zero point, one to set the max point, and a middle one to set the curve.
Yes, they can be. Self-diagnosing isn't a great idea; lots of non-depressed people have some symptoms of depression. It would probably be a good idea to find someone to talk with though.
Every place I'v worked has celebrated fixing things that have broken, and forces engineers to fight for prevention. It's not exactly celebrating things breaking, but it sure looks a lot like it.
Just rgb filters aren't really going to get you anything better than a bayer matrix for the same exposure time, and most subjects on earth are moving too much to do separate exposures for 3 filters.
The benefits of a mono camera and rgb filters is that you can take advantage of another quirk of our perception; we are more sensitive to intensity than color. Because of this, it's possible to get a limited amount of exposure time with the rgb filters, and use a 4th "luminance" filter for the majority of the time. During processing you can combine your rgb images, convert that to HSI and replace the I channel with your luminance image. Because the L filter doesn't block much light it's faster at getting signal, but it's only really a benefit for really dark stuff where getting enough signal is an issue.