Repository navigation
Pyxel submission #262
Description
Submitting Author: @flemmel or for Gitlab: https://gitlab.com/frederic.lemmel
All current maintainers: from Gitlab: https://gitlab.com/vinzaff and https://gitlab.com/benoit.serra
Package Name: pyxel
One-Line Description of Package: Pyxel is a easy-to-use general detector simulation framework that can simulate a variety of imaging detector effects combined on images (e.g. radiation and optical effects, noises) made by CCD or CMOS-based detectors.
Repository Link: https://gitlab.com/esa/pyxel
Version submitted: 2.12
EiC: @crhea93
Editor: @dhomeier
Reviewer 1: @hamogu
Reviewer 2: @crhea93
Archive: TBD
JOSS DOI: TBD
Version accepted: TBD
Date accepted (month/day/year): TBD
Code of Conduct & Commitment to Maintain Package
- I agree to abide by pyOpenSci's Code of Conduct during the review process and in future interactions in spaces supported by pyOpenSci should it be accepted.
- I have read and will commit to package maintenance after the review as per the pyOpenSci Policies Guidelines.
Description
Pyxel is an open-source, modular Python framework for simulating detector effects in imaging sensors such as CCDs, Monolithic CMOS, and Hybrid CMOS devices.
It allows users to input images, configure detector and model parameters through a simple interface, and simulate effects like cosmic rays, PSF, electronic noise, CTI, persistence, dark current, and charge diffusion.
The framework outputs images combining these effects and also provides image analysis tools, an image generator, parametric studies,
and model calibration capabilities.
Designed primarily for detector scientists and engineers in astronomy and Earth observation, Pyxel helps interpret laboratory data,
guide detector design, and predict instrument performance, while promoting reuse of models across projects to foster collaboration and
reduce duplication of effort
Scope
-
Please indicate which category or categories.
Check out our package scope page to learn more about our
scope. (If you are unsure of which category you fit, we suggest you make a pre-submission inquiry):- Data retrieval
- Data extraction
- Data processing/munging
- Data deposition
- Data validation and testing
- Data visualization1
- Workflow automation
- Citation management and bibliometrics
- Scientific software wrappers
- Database interoperability
Domain Specific
- Geospatial
- Education
Community Partnerships
If your package is associated with an
existing community please check below:
- Astropy:My package adheres to Astropy community standards
- Pangeo: My package adheres to the Pangeo standards listed in the pyOpenSci peer review guidebook
- For all submissions, explain how and why the package falls under the categories you indicated above. In your explanation, please address the following points (briefly, 1-2 sentences for each):
Pyxel falls under the category of “data processing/munging” because it applies a pipeline of physical models to CCD and CMOS detectors,
transforming input data into an output image that simulates what the detector would record in practice.
- Who is the target audience and what are scientific applications of this package?
The target audience of Pyxel is:
- Detector scientists and engineers: designing, calibrating, and testing CCD/CMOS detectors.
- Instrument teams: working on space- and ground-based telescopes, payload validation, and performance prediction.
- Astronomers & astrophysicists: who need to understand how detector effects influence scientific measurements.
- Mission designers & ESA/NASA instrument consortia: to validate detector performance before building hardware.
The scientific applications of Pyxel are:
-
Detector characterization: reproducing effects such as charge transfer inefficiency, inter-pixel capacitance, dark current, persistence,
or radiation damage to compare with laboratory measurements. -
Performance prediction: forecasting how CCD and CMOS detectors behave under mission-specific conditions
(e.g., low flux, cosmic rays, varying temperatures, long exposures). -
Instrument design & optimization: testing detector architectures, readout strategies, and noise budgets before building hardware.
-
Calibration & correction development: generating realistic synthetic datasets with known detector effects to design and validate data-reduction algorithms.
- Are there other Python packages that accomplish the same thing? If so, how does yours differ?
Yes, there are other simulation packages, for example:
-
PhoSim (Photon Simulator): Developed for the LSST (now Rubin Observatory).
It simulates the atmosphere, telescope optics, and CCD detector effects, but is highly specialized for that mission and less modular for general use. -
Mirage: A NASA toolkit for simulating JWST’s NIRCam and NIRISS detectors.
It provides high-fidelity simulations but is tailored to specific instruments and data formats. -
ScopeSim: A Python framework for simulating telescope instruments.
It models the atmosphere, telescope optics, and instrument throughput, with simplified detector modeling. However, it is less suited for detailed, pixel-level detector physics.- If you made a pre-submission enquiry, please paste the link to the corresponding issue, forum post, or other discussion, or
@tagthe editor you contacted:
APE 22 follow-up: Candidates for pyOpenSci trial review period astropy/astropy.github.com#571 and Pyxel affiliated package: Pyxel astropy/astropy.github.com#516
- If you made a pre-submission enquiry, please paste the link to the corresponding issue, forum post, or other discussion, or
Technical checks
For details about the pyOpenSci packaging requirements, see our packaging guide. Confirm each of the following by checking the box. This package:
- does not violate the Terms of Service of any service it interacts with.
- uses an OSI approved license.
- contains a README with instructions for installing the development version.
- includes documentation with examples for all functions.
- contains a tutorial with examples of its essential functions and uses.
- has a test suite.
- has continuous integration setup, such as GitHub Actions CircleCI, and/or others.
Publication Options
- Do you wish to automatically submit to the Journal of Open Source Software? If so:
JOSS Checks
- The package has an obvious research application according to JOSS's definition in their submission requirements. Be aware that completing the pyOpenSci review process does not guarantee acceptance to JOSS. Be sure to read their submission requirements (linked above) if you are interested in submitting to JOSS.
- The package is not a "minor utility" as defined by JOSS's submission requirements: "Minor ‘utility’ packages, including ‘thin’ API clients, are not acceptable." pyOpenSci welcomes these packages under "Data Retrieval", but JOSS has slightly different criteria.
- The package contains a
paper.mdmatching JOSS's requirements with a high-level description in the package root or ininst/. - The package is deposited in a long-term repository with the DOI:
Note: JOSS accepts our review as theirs. You will NOT need to go through another full review. JOSS will only review your paper.md file. Be sure to link to this pyOpenSci issue when a JOSS issue is opened for your package. Also be sure to tell the JOSS editor that this is a pyOpenSci reviewed package once you reach this step.
Are you OK with Reviewers Submitting Issues and/or pull requests to your Repo Directly?
This option will allow reviewers to open smaller issues that can then be linked to PR's rather than submitting a more dense text based review. It will also allow you to demonstrate addressing the issue via PR links.
- Yes I am OK with reviewers submitting requested changes as issues to my repo. Reviewers will then link to the issues in their submitted review.
Confirm each of the following by checking the box.
- I have read the author guide.
- I expect to maintain this package for at least 2 years and can help find a replacement for the maintainer (team) if needed.
Please fill out our survey
- Last but not least please fill out our pre-review survey. This helps us track
submission and improve our peer review process. We will also ask our reviewers
and editors to fill this out.
P.S. Have feedback/comments about our review process? Leave a comment here
Editor and Review Templates
The editor template can be found here.
The review template can be found here.
Footnotes
-
Please fill out a pre-submission inquiry before submitting a data visualization package. ↩
Metadata
Metadata
Assignees
Type
Projects
- Status
Activity
eliotwrobson commentedon Sep 9, 2025
@flemmel thanks for your submission! I'll be able to start on the pre-review-checks soon 👍🏽
dhomeier commentedon Nov 26, 2025
Editor in Chief checks
Hi again! Sorry for the delay in completing the pre-review checks. I am happy to report that your package passes
all basic checks required to begin our review.
Please check our Python packaging guide for more information on the elements
below.
import package.README.mdfile with a clear explanation of what the package does, instructions on how to install it, and a link to development instructions.CONTRIBUTING.mdfile that details how to install and contribute to the package.CODE_OF_CONDUCT.mdfile.NOTE: We prefer that you have development instructions in your documentation too.
YAMLheader of the issue (located at the top of the issue template).Optional: Let projects know that it's a great idea for projects to have a .github repository for the project organization where they can host a commonly used LICENSE, Code of Conduct, and even a YAML file with label definitions. These items will then be automatically applied to every repository in the organization to ensure consistency (but can be customized within repos too). The SunPy project has a great example of this. (Unfortunately I don't have a corresponding example at hand for GitLab)
We appreciate each maintainer of the package filling out this survey individually. 🙌
Thank you, authors, in advance for setting aside five to ten minutes to do this. It truly helps our organization. 🙌
Editor comments
pip install pyxel-simjust as well as from the recommended environment.yaml, but the former did not automatically pull in the jupyterlab install required to run the example tutorials.flemmel commentedon Nov 30, 2025
Hi @dhomeier !
Thanks for your detailed review, I really appreciate it.
Just to clarify, we are not aiming for an active partnership with the Pangeo community but rather with the Astropy community.
Pyxel relies heavily on Astropy for many core features including:
astropy.io.fits)astropy.table.Table)astropy.units.Quantityandastropy.constants)astropy.coordinates.SkyCoord)astropy.convolution.convolve_fft)Pyxel also depends on several affiliated Astropy packages such as
photutils,astroqueryandspecutils.Do you have any suggestions on how we should proceed?
dhomeier commentedon Dec 1, 2025
Thanks for your confirmation @flemmel; yes we have filed this under Astropy and will assign an editor and at least one reviewer familiar with the Affiliated Package system. We had just discussed to additionally review Pangeo criteria as an extra if the opportunity arises, since that box was checked as well.
If @eliotwrobson confirms I think we are ready to proceed to the next steps; nothing left to do on your side for the moment! It would be nice if the other maintainers found time to fill out the onboarding survey as well, but I think we don’t need to wait for that.
eliotwrobson commentedon Dec 16, 2025
@dhomeier all looks good to me 👍
1 remaining item
dhomeier commentedon Feb 11, 2026
@flemmel apologies for the further delays that arose from the EiC rotation, just a heads-up that your submission is now in my hands as editor and under review by two experienced reviewers, so we hope to make good progress from here on.
flemmel commentedon Feb 12, 2026
No worries @dhomeier ! Let me know if you need any further inputs from my side.
hamogu commentedon Mar 26, 2026
Package Review
Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide
Documentation
The package includes all the following forms of documentation:
pyproject.tomlfile or elsewhere.Readme file requirements
The package meets the readme requirements below:
The README should include, from top to bottom:
NOTE: If the README has many more badges, you might want to consider using a table for badges: see this example. Such a table should be wider than high. A badge for pyOpenSci peer review will be provided when the package is accepted.
Usability
Reviewers are encouraged to submit suggestions (or pull requests) that will improve the usability of the package as a whole.
The package structure should follow the general community best practices. In general, please consider whether:
Functionality
A few notable highlights to look at:
For packages also submitting to JOSS
Note: Be sure to check this carefully, as JOSS's submission requirements and scope differ from pyOpenSci's in terms of what types of packages are accepted.
The package contains a
paper.mdmatching JOSS's requirements with:Final approval (post-review)
Estimated hours spent reviewing: 8
Review Comments
I'm still running through the functionality. I want to actually set up my own example of a detector and run the fitting mode to see if I get it right. Thus, I left the "Any functional claims of the software been confirmed." box empty for now and will update after I've done that, but I wanted to get the bulk of my review to you so you can look at it, and start to address or discuss it.
Note to editor: The supported Python versions are clearly listed in the README, just not in the form of a badge. I think that's perfectly fine and thus I ticked the "badges" box in the README part of the review. Similarly, the installation instruction are general with a link instead of fully spelled out in the README. Again, I think that's great, so I ticked all the boxes.
Docs
Pyxel has an enormous amount of documentation compared to most packages that we require at PyOpenSci. It's clearly a mature, well-developed package. However, I feel that it goes far too deep in some cases, but then is too shallow in others.
I feel that the documentation is organized backwards. If I follow docs, I see them in the following order: tutorials, examples, how-to guides, background/explanations.
I had expected that the tutorial runs through commented threads, then the example give and explain specific examples. I just don't understand them, because there is very little text. Sure, I can run the notebooks (but see esa/pyxel-data#18) but without explanations I don't know why any of this is done and thus I can't modify it to my own needs. The later I get (How-to guides and background/explanation) the more text I get. I understand the urge not to explain every concept in the beginning, but I also don't see the point of code examples with no explanation whatsoever. I suggest to write a little more text into each of te "tutorials and examples".
Installation instructions cover several pages and are written for a large range of package managers (uv, pixi, and miniconda in the quickstart and then in the tutorials there is conda, mamba, and pip and of course there are also "from source" instructions somewhere). I tried only one of those ways and it works; but I think it might be clearer to slim this down and remove a few or delegate them to a page "other installation options" that's not part of the normal flow of tutorials. For example, mamba is essentially a drop-in replacement for conda and mamba users usually know that. I don't think Pyxel itself gains much from a mamba vs conda or pixie vs. uv discussion. When I get to the Pyxel docs, I'm not looking for advice on which package manager I should be using, I just want to install the code.
On the other hand, some of the otherwise comprehensive documentation suddenly falls flat with empty sections, e.g. in tutorial 8 (exposure mode with multiple readout times), there is a section 8.9 that is empty. Other sections, e.g. sect 8.8 (to stick with the same example) have huge output embedded, but relatively few explanatory words. In tutorial 8 (again, just sticking with the same example) the "summary" (section 8.5) has in fact more explanatory text than all following sections combined. I'm not asking for a novel, just a couple of sentences in each sections that I can read before I get hit with a wall of text output. I can see how commands are called, but I'd like to know why. You can be selective - leave holoviews to the excellent holovies docs, just add some text to the sections that actually deal with Pyxel itself.
When I go from tutorials to "examples" there is even less readable text. It's true in all of the examples, but to pick out one: "Observation - Custom" has the stated learning goal "Running Custom Observation mode". But how am I going to learn that? There is a link to an example YAML files, then I call pyxel, and then plot the results. How does this differ from the "sequential" or "product" example? It's essentially the same except for using a different YAML file. To me, it would be more useful to have one example with added text that says what's going on, e.g. say "For sequential or custom observations, change this XXX and YYY in the YAML file and then use the same code as above".
There are no instructions on how to run the tests for users. It's hidden in the developer page and doesn't work out-of-the-box (esa/pyxel#1021).
While PyOpenSci doesn't have a checkbox for "examples in docs all work", it's common sense that they should. See (esa/pyxel#1022) for that.
Software functionality and best practices
While I understand the origin of this design decision (so that you can easily transform strings from YAML to callable functions), I think there should be some separate mechanism to do that. See esa/pyxel#1023 for ideas on how to implement that with relatively little complexity.
crhea93 commentedon Mar 26, 2026
Hi everyone. I just wanted to let you know that I will be completing my review next week. My apologies for the delays.
flemmel commentedon Mar 26, 2026
Hi @hamogu,
Many thanks for taking the time to review the documentation, I really appreciate it !
All your points (and your GitLab issues) are absolutely valid. We are indeed missing clear and accessible documentation both for specialist and more importantly for non-specialists.
In particular, we will add better explanations about the different detector families, where the models are applied and how to quickly and easily build a simulation pipeline.
Thanks again for your feedback. We will address the issues you created and more (esa/pyxel-data#19, esa/pyxel#1024, era/pyxel#1025).
We are also actively working on improving Pyxel's usability, including better documentation, integration of a MCP server (for LLM), a GUI and a catalogue of pre-configured pipelines.
crhea93 commentedon Apr 12, 2026
Package Review
Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide
Documentation
The package includes all the following forms of documentation:
pyproject.tomlfile or elsewhere.Readme file requirements
The package meets the readme requirements below:
The README should include, from top to bottom:
NOTE: If the README has many more badges, you might want to consider using a table for badges: see this example. Such a table should be wider than high. A badge for pyOpenSci peer review will be provided when the package is accepted.
Usability
Reviewers are encouraged to submit suggestions (or pull requests) that will improve the usability of the package as a whole.
The package structure should follow the general community best practices. In general, please consider whether:
Functionality
A few notable highlights to look at:
For packages also submitting to JOSS
Note: Be sure to check this carefully, as JOSS's submission requirements and scope differ from pyOpenSci's in terms of what types of packages are accepted.
The package contains a
paper.mdmatching JOSS's requirements with:Final approval (post-review)
Estimated hours spent reviewing:
Review Comments
Thank you for the package submission! Please see my comments below:
Much of the tutorials are lacking additional context. For example, take the first tutorial (tutorial 2). At the end the authors show the results but they don't talk about what they are supposed to be looking at. More importantly why does the third image in the bottom section look like it has less counts?
I second all the by @hamogu. I will do an additional thorough review of those points once they have been addressed.
flemmel commentedon Apr 13, 2026
Thank you @crhea93 !
We will add more context to our tutorials and will get back to you once it’s done.
crhea93 commentedon Sep 11, 2026
Hi @flemmel I just wanted to step in and check out how things are going with the updates to the package following the reviewer comments in my role as EiC. Hope all is well!!
flemmel commentedon Sep 20, 2026
Hi @crhea93 !
Thanks for the reminder ! I have already made quite a few modifications. I will finish the remaining ones over the coming weeks and get back to you once it is done !
crhea93 commentedon Sep 21, 2026
Fantastic! Thank you!
kysolvik commentedon Nov 2, 2026
Hi @flemmel! Just checking in on how things are going with the changes. Thanks!