Added proposal to modify ds9 to work with ASDF files.

[perrygreenfield]

No description provided.

[pllim]

But what of the maintenance status of DS9 itself?

[perrygreenfield]

I presume they have minimal maintenance at this point. Perhaps I'm wrong.

[pllim]

So do we run the risk to submitting code to the void?

[hamogu]

Speaking as a CXC/SDS member here (the group at CXC that also maintains DS9, though that's not my task): As of now, DS9 is fully maintained with the same full-time developer who has worked on DS9 for literally decades; releases happen at regular cadence and long-term development plans are being executed (don't ask for the details, something about underlying GUI toolkit migrations and future MacOS incompatibilities). As long as the CXC is funded, DS9 will be maintained in this form (though the developer might retire at some point and be replaced by a new hire). DS9 is probably among top, of not the top priority for SDS - so as long as there is SDS finding, there will be ds9 support.
Now, notice that I said "as long as the CXC is funded". At this stage of the US government, it's hard to make a long-term or even short-term prediction. The CXC is in both the House and the Senate's budget for FY 2026, thus the probability that the CXC will continued to be funded in the near term is high (assuming there will be a FY26 budget in the US eventually). What's beyond FY26? Hard to say. On a technical level, Chandra can continue to operate for at least a decade (barring any unforeseen hits by meteoroids etc.), so the limit is purely set by NASA funding.
I admit that Chandra is an aging observatory, but there is no replacement under construction in the US (AXIS is in Phase A, but even if granted won't fly till 2031 at the earliest) and NewAthena in Europe won't launch before 2038 or so. Thus, in the grant scheme it makes sense to continue to run an X-ray observatory, which implies that the CXC would continue to fund the development of DS9.
Can I give a long-term guarantee? No. My personal guess is that that the CXC will continue to run in some form for at least 3-5 years - but your guess is as good as mine.
The CXC shut-down plan involves passing all data and software for continued minimum maintenance to HEASARC@Goddard. According to that plan, ds9 should therefore we available for the next few decades, but maybe not with active development.
Alternative funding models for ds9 are pursued (e.g. private foundations, other NASA programs) for the future. I don't know if any of that comes through, but I can promise that continued active development of ds9 is a high priority for CXC/SDS even when looking at a post-Chandra future.

[hamogu]

Comment: Has the project team reached out to the current DS9 lead developer to discuss the feasibility of the idea and how code contributions would be handled in practice?

[astrofrog]

While I think this would be great to have, I think this proposal could be strengthened in two ways:

• While time is short until the deadline, I think it would be ideal to get in touch with the DS9 developer(s) to get their approval in principle, as this proposal is so critically depending on that.

• Currently this does not link to any astropy roadmap items (see other proposals for some examples), but it would be good to add this - and perhaps add more detail about how this benefits the Astropy project (since ASDF is a STScI product rather than a product of Astropy)

[astrofrog]

Does this make use of pyds9? Or is it different?

[perrygreenfield]

@hamogu I have not reached out to the development team (I recall a little ways back that there questions about support, so it is good to hear that is not a problem). It was suggested basically the day before the proposal deadline so I did not have time to do that. I must have been under the mistaken impression Bill Joye had retired (or did and then was roped back in?). I will contact him about this proposal. As mentioned the first task is independent of any needed changes to ds9, but the subsequent ones do require changes.

[perrygreenfield]

@astrofrog the original implementation of the first step did not use pyds9, but that was long enough ago that I don't recall the reasons. It may be usable now. I have to check into that.

[kelle]

It would be useful for this funding request to have a budget range.

[perrygreenfield]

As for a budget range, I'd say $18K to $22K. I have changed the PR to state it this way.

[perrygreenfield]

I had not been getting notifications from github because of email configuration issues with github. I think those are fixed now.

[AnaGabela]

Please react to this comment to vote on this proposal (👍, 👎, or no reaction for +0).

[pllim]

My vote might change if we hear back from DS9 development team. I don't want us to throw money into a blackhole.

[neutrinoceros]

Same.

update 2025-12-04: just changed my vote from -1 to +1

[perrygreenfield]

I did send an email to Bill Joye but have not heard back from him.

I'll also note the first phase of the proposal does not require any changes to ds9.

[nden]

While we can't force the DS9 development team to reply, a large portion of the astronomy data in the next decade is going to be in ASDF format. Being able to display ASDF files in DS9 is going to be very helpful for a quick lookup. While jdaviz (the only visualization tool working with ASDF now) is turning into a data analysis tool, I believe a simple, quick visualization tool will be welcome.

[pllim]

FWIW I think Ginga has some basic ASDF support already (https://github.com/ejeschke/ginga/blob/main/ginga/util/io/io_asdf.py) and it is also Astropy Affiliated. I did not get a chance to do a full fledge JWST support because of reasons but it was used in commissioning.

[hamogu]

a large portion of the astronomy data in the next decade is going to be in ASDF format

You probably know more about future adoption, but Chandra isn't going to change from fits, and as far as I know neither are Gemini, Keck, ESO, or ESA. Radio and Gammay-ray astronomy are using non-fits formats already to a varying degree, but their formats are not ASDF either.

That's not to say that we should not fund this proposal, that it's not important in the cases that it is used,nor that ASDF would not take off in the future, but as far as I can see, it's currently only used if a very specific corner of astronomy by a relatively small fraction of the community (JWST).

[perrygreenfield]

Don't forget Roman as well, where it is the native format for that.

There are some orthogonal points being raised. For example, although there are other tools that can handle ASDF, not being supported by the most heavily used tool by astronomers is a major issue for adoption. To some extent there is a chicken and egg issue here. Not being easily used by existing tools inhibits its use. And then it not being used is an argument for not supporting it.

A separate point (which I will update the PR with soon) is that I have discovered there are tools to extend the ds9 user interface without requiring changes to ds9 itself (unless those tools no longer work). So the work would take that approach with the eventual hope that ds9 would incorporate those features later fairly easily. The drawback is that it puts the burden on the user to install these extensions, which is a obvious hassle. Even so, demonstrating that the work has been done without requiring commitments from the development team is an important feature.

[neutrinoceros]

How difficult would it be to upstream extension code into ds9 itself, if the opportunity arises ?

[perrygreenfield]

LGTM (do these proposals really require review by an independent person?)

[perrygreenfield]

@neutrinoceros That depends on the details. In the examples I saw there was use of a separate process to handle certain things IIRC. Incorporating a C extension would be a bigger deal, but I don't think that would be necessary for this work. It likely would require optionally setting up a Python process to handle the I/O for the file and using one of the methods for transmitting the image data and WCS to ds9. Whether this would be done as a subprocess or a server process within ds9 is currently unclear to me at the moment. There is a C version the ASDF library being developed, and that could eliminate the need for a separate process.

[neutrinoceros]

Ok then, what kind of tools are we talking about ? Would your extension(s) need to rely on third party code at runtime, and if so, how reliable do you think these might be ? (Trying to estimate the risk that your work ends up being broken by factors external to us and ds9)

[perrygreenfield]

At the moment I think only either the python ASDF library or possibly the C ASDF library. The first drags in all the necessary python dependencies, of course. Perhaps some Tcl/Tk modules not used by ds9 but probably not. I can't think of any other 3rd party code. It could be made an optional dependency that ds9 doesn't take responsibility for, e.g., if not found, it doesn't take responsibility for that functionality not working and keeps its core interface. There are probably a few ways to deal with this.

[neutrinoceros]

sounds reasonable; thank you !

[kelle]

The Cycle 5 funding request process has been hugely successful! On the downside, that means our funds are severely oversubscribed. Even after the Finance Committee and SPOC have taken into consideration community feedback/voting and alignment with the roadmap, there are still more funding requests than we can afford in 2026.

We would like to stretch the budget as far as possible, and to fund as many activities as possible, while making sure the Project remains volunteer-driven. Hence, we would like to know if this project will still meet its deliverables if your minimum budget is reduced by 25%, 50%, or 100%. Or if there’s some other minimum, feel free to specify that instead.

As a reminder, there will be more funding for 2027 and we expect the Cycle 6 call for 2027 funding requests to begin in the Fall of 2026.

Thank you for your engagement and understanding as we continue to optimize our funding and budgeting processes and the balance of volunteer vs funded work!

(@perrygreenfield )

[perrygreenfield]

I'd say that some of the important goals could be achieved with 50% funding, but obviously not as much would be accomplished. The first two would certainly be practical. Any less than 50% makes the project impractical in my opinion.