Some are fair – of course this is a simplified visualization! Observationally, we don't really know how fast a given black hole is rotating, and here I indeed assumed a non-rotating one. It's not an inaccuracy per se, more like a missing feature. The camera mode has a (half-hidden) toggle to enable Kerr metric and set spin, but even there it's not a default.

I consider the colormap choice to be completely arbitrary though, without affecting accuracy. Basically, it represents intensity at a given frequency, the image like one would get from a telescope. It wasn't intended as a faithful optical color representation! And really, in my (admittedly biased) view of a radio astronomer, I tend to assume frequencies invisible to the human eye anyway.

▲

20k 10 hours ago | parent | next [-]

>of course this is a simplified visualization

Its titled a "physically accurate black hole"! Please don't do this, if its intentionally not physically accurate and heavily simplified! The general public on here don't know better, and it takes someone else with years of experience simulating black holes to dig through your code to show what you've simplified. There's like a few hundred people who have the right experience worldwide to know that you've got some of your equations incorrect

The issue is when you're communicating doppler, if you want to correctly show the change in doppler, you can't make the intensity or colour mapping arbitrary

There's two ways to communicate accurately an example linear change in emissive power:

1. Use a perceptual brightness system, so that a linear change in power represents a linear perceptual change in perceived brightness. This accurately communicates to a viewer the underlying shift in power emission, if you want to show off how a radio telescope perceives a black hole for example

2. Use an emitted power <-> sRGB mapping (with tonemapping), so that a linear change in power is perceived as if it were a physical light getting brighter. This is more "what would this look like to a person?"

At the moment the change in your image brightness doesn't correspond to anything, which means that its not really communicating any science, and it doesn't correspond to doppler. Which is fine if its just illustrative and that's clear, but again vanishingly few people will know this is a visualisation not a physically accurate render

▲

aplavin 10 hours ago | parent | next [-]

> Its titled a "physically accurate black hole"! Please don't do this, if its intentionally not physically accurate and heavily simplified!

It also doesn't exert the gravity an actually accurate black hole should :) And also, even on a phone with two cameras, they only cover a part of sphere – while a real black hole would bend light coming from all 4pi directions. Some simplification is generally required ("the map is not the territory") and I don't see "simplified" as being opposite to "accurate".

Colormap choice: it can be a useful mode to show proper linear power -> linear perceived brightness mapping – true! But that's only one of many possible choices, and scales like logarithmic are very common in scientific images.

▲

20k 10 hours ago | parent | next [-]

>I don't see "simplified" as being opposite to "accurate".

Are black hole accretion disks generally red in real astrophysical cases?

They're most accurately represented as being blue. Red is fine for visualisations because it looks cool (which is fine!), but blue is the physically accurate colour. Visualisations claiming to be accurate like this presenting red black holes is becoming an increasingly large science communication problem

The way that the colour and brightness are mapped together is also not correlated correctly, and some of the equations just aren't right. The doppler isn't correct at all here, partly because its simulated incorrectly (with the camera problems), and partly because the mapping done at the end doesn't correlate to any reasonable brightness

Stuff like this: Its not accurate at all. It isn't simplified, its just wrong - which is totally fine for a visualisation, if that's the intent. But:

>scales like logarithmic are very common in scientific images.

Sure. What scale are you using for the doppler brightness here? Because as far as I can tell, its a piecewise mapping of the form ~pow(x, 2.2), after being run through a non smooth function `afmhot` - a function which doesn't have a linear brightness response. So the brightness in this image doesn't really correspond to anything related to doppler or brightness, and the colour also doesn't correspond to anything involving colour (or the doppler). The entire image's look is basically accidental

Here's a specific comment from the event horizon telescope talking about exactly this problem with specifically the afmhot transform being used, because its important for visualisation:

https://github.com/achael/eht-imaging/issues/85

Which shows some of the problems here

▲

EugeneOZ 9 hours ago | parent | prev | next [-]

“Physically accurate” indeed raises the bar significantly.

You’ve already done great work here. That said, the feedback seems to come from someone who spent considerable time analyzing your work. Even if only a few of the suggestions are ultimately valuable, that’s still a meaningful contribution and worth considering.

	▲	aplavin 2 hours ago \| parent [-]
		Sure, most of the raised questions are reasonable potential feature additions to be made – things like rotating black holes, or linear brightness-to-screen-pixel mapping. They just aren't "inaccuracies", in my opinion.

▲

7bit 4 hours ago | parent | prev [-]

Always funny when people claim that scientific term apply to their software and then disregard any founded criticism in a non scientific way.

▲

20k 39 minutes ago | parent [-]

Its frustrating because these issues are all fixable, and some of them are just bugs, but there's a mentality in this kind of science communication that ehh it doesn't matter because its just for the public. This does a real disservice to what people are trying to actually achieve in educating the public. Its also, unsurprisingly, a lot of hard work and validation to get from visualisation-grade, to physically accurate, and its a lot easier to not do that

▲

aplavin 31 minutes ago | parent | next [-]

Note that most of the points you raised are clearly not bugs – most notably, things like non-rotating black hole or colormap choice. At the very most, these can be considered missing features, but they don't affect correctness in any way.

	▲	andrecarini 2 minutes ago \| parent [-]
		You seem more interested in putting effort downplaying criticism and upholding the optics of "scientifically accurate thing from researcher in big name university" than actually putting effort on making the thing good and using the amazing feedback you got

▲

7bit 15 minutes ago | parent | prev [-]

I don't understand what you are saying.

The only criticism is to call that accurate, when it's simplified. OP ist defending the use of accurate with dumb arguments. The fix would simply be to not claim "accurate" and continue to provide a probably great visualisation (idk, haven't looked at it)

▲

fwip 2 hours ago | parent | prev [-]

It's AI garbage - OP asked the LLM for "physically accurate", Claude gave them this, and they didn't know any better.

▲

john_strinlai 2 hours ago | parent [-]

>and they didn't know any better.

i think an "astrophysicist at Harvard's Black Hole Initiative studying quasars and black hole environments" who "work[s] with raytracing/radiative transfer simulations professionally"probably has a decent understanding of what's going on...

▲

fwip an hour ago | parent [-]

You'd think, and yet, they happily slapped the Harvard BHI name on something that doesn't do what it says on the tin. I think ignorance is preferable to deliberate deception, so I assumed ignorance.

	▲	john_strinlai an hour ago \| parent [-]
		i think they've made some decently reasonable comments explaining their choices, whether you agree or not, and coming in with a shallow dismissal solely consisting of "llm garbage, must be an idiot" is a pretty shitty thing to do (let alone specifically against the rules). 20k's comments open up conversation and engage with the content. yours is just boring, encourages no conversation, and is basically a copy/paste of thousands of other worthless comments. the only thing your comment accomplishes is making hn a worse place.

▲

yoaviram 8 hours ago | parent | prev | next [-]

Great job. Please consider turning on rotation by default (for those who missed it, it's in the parameters). The overwhelming majority of astrophysical black holes are expected to be spinning (Ker) black holes.

	▲	aplavin 39 minutes ago \| parent [-]
		That option for rotating (Kerr) black holes generally works, but not on all devices in my experiences. Debugging on someone's phone is not that straightword, so I went with the most accessible experience by default. Also note that the visual difference for the camera warp is really marginal between rotating vs non-rotating black holes.

▲

gilrain 3 hours ago | parent | prev [-]

> completely arbitrary

You agree that it isn’t “physically accurate”, then… but seem to argue that you shouldn’t be called out for the false title?

It’s fair enough to be called clickbait when you really did score extra clicks with a slick falsehood, surely?

	▲	aplavin 36 minutes ago \| parent [-]
		Arguing about colormap choice seems very strange to be – this is such a common practice in astronomy (and other fields!). The vast majority of images you see in published papers apply some arbitrarily-chosen colormap and color scheme. No matter if you look at observational or theory papers, it's very rare to find a real true-color image. And for a bunch of good reasons! The only difference here is that I don't show a colorbar with explicit color-number mapping, for simplicity sake.