cconstantine

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.

How about a talk by an expert on the topic of noise in an image: https://www.youtube.com/watch?v=3RH93UvP358

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.

Oh nice! Except for Alnitak (I love me some spikes), I like yours more.

Well, if you think photography is too easy you could try taking up astrophotograhy :)

Thanks, but it if you look closely you'll see that the Webb image has almost an image worth of detail within each pixel of my image.

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.

Awe shucks, thanks :blush:

Absolutely incredible.

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.

Yes, you can :)

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.

It's kinda like a gamma correction.

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.

This means no one can even tell you were bankrupt after 7-10 years, which is pretty incredible feature for borrowers.

This is absolutely not true. The record of your bankruptcy lives in the public records of the bankruptcy court forever.

I'm going to assume you're a business person.

Commerce is vulgar, but as long as you're making (b|m)illions off me could you let me do my thing? Stop taking things that work for tech folk, misapplying them to business concerns without any intellectual honestly and deciding they don't work for anyone. Metrics work. The problem you people have with them is that they are a branch of statistics and if there's one thing business folks love to do it's lie with statistics. It's all fun and games until you start lying to yourself and start seeing the negative consequences.

How do you propose I escape the KPI game? It's how I'm evaluated by people who pay me. It's become how you gain influence in an organization. I can't escape to another place, because they all operate this way now. More and more I'm seeing "tech" leaders, big and small, that are much better at playing the game than holding any kind of technical excellence.

I'm not looking for some idealized world. At this point, I'm looking to have some fun while I get taken advantage of.

I'm not saying bankruptcy is bad. It's a necessary escape hatch for the credit industry, and shouldn't have the stigma it does. maunder is absolutely right; the consumer credit industry in the US is nothing but predatory. Good for you if you haven't been bit yet, but their goal is to eat everyone. Whenever I see someone brag about their credit score all I see is a mouse begging for the cat's approval.

More and more you can't even opt out of consumer credit. I have attempted to opt out of it by not holding any credit, except I apparently need good credit to live somewhere, or a credit card to rent a car or do some kinds of money transfers.

Telling people they can file bankruptcy, "reset to 0", and have another chance to redeem themselves is bullshit. The only place it disappears from is your credit report, and implying that covers it is a brazen lie. It really doesn't. Fuck credit scores. What about the ability to get a job, or not live on the street? Having a bankruptcy from 30 years ago can negatively impact your ability to do either of those things.

The credit industry is so deluded that they think your credit report is all that matters, and that's how they want you to think. In reality, it's all that matters to them and they can't wait to get you back in the game.

Creditors love people who have recently filled for bankruptcy. They're vulnerable, known to be bad with money, and can't file again for a number of years.

This is a lie that needs to die. Bankruptcy might get removed from your credit report, but the public court records never do. Anyone who does a credit check can (and will) search those public records.

Bankruptcy stays with you forever.

Net Promoter Score: https://en.wikipedia.org/wiki/Net_promoter_score

How likely are people to promote the thing?

The only thing that matters is revenue, and if it can't be easily measured against revenue it doesn't exist. I am so tired of this line of reasoning. It's poisoning the industry, ruining products, and sucking the joy out of work.

What about making a quality product because you have a passion for it? Nope, make a broken MVP and move on to the next customer.

If I can't maintain a metric until I can tie it to revenue, then I guess I don't get cpu usage on our database. Or disk usage. Or response time for anything that only employees touch. Bad data and errors are fine as long as no one complains. Actually, if we produce a shitty product long enough everyone will get used to it and stop complaining. If we stop measuring error rates we can stop wasting time on fixing things right? Tests and code refactors just get in the way of delivering that MVP. Rewards are doled out for fixing an outage, and preventing them is a cost-center to be eliminated.

On the flip side, now we've got KPIs for our ability to push things through the corporate bureaucracy. I didn't become a programmer so I can waste time estimating how long it'll take to produce a design doc that'll be useless by the time I get to implementation, just so a bureaucrat can decide if some deeply technical problem they don't understand should be fixed.

There has to be a better way.

install python and use pip

Now you've given your users 2 issues completely unrelated to the problem they're trying to solve. If you can't give your users a single simple command, or a single file to download your tool is too complicated to install.

People don't often think of their local development environment as a "platform" that their stuff needs to work in, but it really is. In that sense, unless you're hosting off of your laptop (please don't!), every app is multi-platform.

Every startup I've worked at (and I've been at this for 15+ years) has moved hosting providers, but I still wouldn't put it high on the list of reasons to avoid vendor lock-in. If you make sure someone(s) know how the app actually runs, and you try to pick stuff you can run locally, the vendor lock-in stuff won't be your biggest challenge in the move.

I'd add another reason: Devs need to be able to run stuff locally sometimes.

It's neat having a serverless single page app that is hosted in s3, served through cloudfront, with lambda's that post messages to sqs queues that are read by god knows what else, but what happens when there's a bug? How do you test it? You can throw more cloud at it and give each dev a way to build their own copy of the stack, but that's even more work to manage. Maybe localstack behaves the same, but can you integrate it with your test framework?

I never took a hard "we must never use aws-only services" approach, but having the ability to run something locally was a huge plus. Postgres RDS? Totally fine, you don't need amazon to run postgres. Redshift? Worth the lock-in given the performance. Lambda? Eh, probably not, given that we already have a streamlined way to host a webapp.