What exactly does helioviewer.org assume about WCS?

[SalimHachemaoui]

We are investigating a SPICE JP2 rendering issue in Helioviewer Web.

The tested SPICE JP2 is a valid 2D raster:

NAXIS  = 2
NAXIS1 = 192
NAXIS2 = 612

However, its WCS metadata is not a simple square-pixel, axis-aligned case:

CUNIT1 = deg
CUNIT2 = deg

CDELT1 = 0.0011111111111111 deg  ~= 4.0 arcsec/pixel
CDELT2 = 0.000305 deg            ~= 1.098 arcsec/pixel

It also contains a non-trivial PC matrix:

PC1_1 = -0.61227620057
PC1_2 = -0.217031764022
PC2_1 = 2.88030582543
PC2_2 = -0.61227620057

This raises a general question: what WCS assumptions does helioviewer.org make in 2D and 3D rendering?

Observed behavior

In Helioviewer Web:

• SPICE can appear mis-scaled or vertically stretched in 2D.
• In 3D, SPICE does not appear correctly overlaid on EUI.
• The behavior differs from JHelioviewer, where SPICE appears to be rendered more consistently.

Main questions

1. Does Helioviewer Web assume CDELT1 == CDELT2?
2. Does Helioviewer Web assume that the image X axis, associated with CDELT1, is parallel to solar_x?
3. Is CROTA2 used in 2D or 3D rendering?
4. Is the PC matrix used in 2D or 3D rendering?
5. Are CTYPE1/CTYPE2 projections, such as HPLN-TAN/HPLT-TAN, supported in Web rendering?
6. Do 2D and 3D use the same WCS assumptions?
7. Is general WCS support expected in helioviewer.org, or only simplified image positioning?

2D / 3D context

From code inspection, the 2D Web path appears to use the tiled rendering pipeline:

getClosestImage -> getTile -> PNG tiles positioned in CSS

The 3D Web path appears to use a separate pipeline:

resources/js/3d -> @helioviewer/sun -> getClosestImage/getJP2Header/downloadImage -> Three.js texture

[dgarciabriseno]

Hello, sorry I didn't have time to review this today, but I will try to have a better response on Tuesday next week. Off the top of my head, it's likely that the 3D view understands WCS better than the 2D view. I am pretty sure you're right in observing that 2D assumes the same CDELT is the same for both axes, which is the wrong assumption. The files you're likley interested in seeing is JP2ImageXMLBox.php, that's the file that processes WCS info, and it does look like it ignores CDELT2. I suppose we haven't noticed since most data we've added in ourselves has been square.

…

On June 3, 2026 7:56:23 AM UTC, salim HACHEMAOUI ***@***.***> wrote: SalimHachemaoui created an issue (Helioviewer-Project/api#494) We are investigating a SPICE JP2 rendering issue in Helioviewer Web. The tested SPICE JP2 is a valid 2D raster: ```text NAXIS = 2 NAXIS1 = 192 NAXIS2 = 612 ```` However, its WCS metadata is not a simple square-pixel, axis-aligned case: ```text CUNIT1 = deg CUNIT2 = deg CDELT1 = 0.0011111111111111 deg ~= 4.0 arcsec/pixel CDELT2 = 0.000305 deg ~= 1.098 arcsec/pixel ``` It also contains a non-trivial PC matrix: ```text PC1_1 = -0.61227620057 PC1_2 = -0.217031764022 PC2_1 = 2.88030582543 PC2_2 = -0.61227620057 ``` This raises a general question: **what WCS assumptions does helioviewer.org make in 2D and 3D rendering?** ## Observed behavior In Helioviewer Web: * SPICE can appear mis-scaled or vertically stretched in 2D. * In 3D, SPICE does not appear correctly overlaid on EUI. * The behavior differs from JHelioviewer, where SPICE appears to be rendered more consistently. ## Main questions 1. Does Helioviewer Web assume `CDELT1 == CDELT2`? 2. Does Helioviewer Web assume that the image X axis, associated with `CDELT1`, is parallel to `solar_x`? 3. Is `CROTA2` used in 2D or 3D rendering? 4. Is the `PC` matrix used in 2D or 3D rendering? 5. Are `CTYPE1/CTYPE2` projections, such as `HPLN-TAN/HPLT-TAN`, supported in Web rendering? 6. Do 2D and 3D use the same WCS assumptions? 7. Is general WCS support expected in helioviewer.org, or only simplified image positioning? ## 2D / 3D context From code inspection, the 2D Web path appears to use the tiled rendering pipeline: ```text getClosestImage -> getTile -> PNG tiles positioned in CSS ``` The 3D Web path appears to use a separate pipeline: ```text resources/js/3d -> @helioviewer/sun -> getClosestImage/getJP2Header/downloadImage -> Three.js texture ``` <img width="1364" height="730" alt="Image" src="https://github.com/user-attachments/assets/7417a145-1a9b-4beb-809e-bad6b453261f" /> -- Reply to this email directly or view it on GitHub: #494 You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[SalimHachemaoui]

Thanks Daniel, that confirms what we observed.
For SPICE, the tested JP2 has CDELT1 ~= 4.0 arcsec/pixel and CDELT2 ~= 1.098 arcsec/pixel, so if JP2ImageXMLBox.php ignores CDELT2 and uses a scalar scale, that likely explains the 2D vertical stretching.
I’ll focus on JP2ImageXMLBox.php for the 2D case and keep the 3D path separate, since it seems to handle WCS differently.

If you think this is the right direction, I can create a dedicated branch to handle these WCS edge cases, especially CDELT1 != CDELT2 and possibly CROTA/PC later, while keeping the current behavior unchanged for standard square-pixel datasets.

[dgarciabriseno]

That would be greatly appreciated! Yes, the 2D and 3D cases are separate since 3D processes WCS on its own, it is passed to the GPU via a shader to scale/orient the image. Please note HelioviewerCompositeImage.php will also need to be updated to handle CDELT2, this handles making images/frames with the screenshot and movie feature.

…

On June 4, 2026 7:50:14 AM UTC, salim HACHEMAOUI ***@***.***> wrote: SalimHachemaoui left a comment (Helioviewer-Project/api#494) Thanks Daniel, that confirms what we observed. For SPICE, the tested JP2 has CDELT1 ~= 4.0 arcsec/pixel and CDELT2 ~= 1.098 arcsec/pixel, so if JP2ImageXMLBox.php ignores CDELT2 and uses a scalar scale, that likely explains the 2D vertical stretching. I’ll focus on JP2ImageXMLBox.php for the 2D case and keep the 3D path separate, since it seems to handle WCS differently. If you think this is the right direction, I can create a dedicated branch to handle these WCS edge cases, especially CDELT1 != CDELT2 and possibly CROTA/PC later, while keeping the current behavior unchanged for standard square-pixel datasets. -- Reply to this email directly or view it on GitHub: #494 (comment) You are receiving this because you commented. Message ID: ***@***.***>

[SalimHachemaoui]

Thanks , that helps a lot.
I’ll keep the 2D and 3D cases separate. For now I’ll focus on the 2D path and the scalar CDELT assumption.
I’ll include JP2ImageXMLBox.php for reading CDELT1/CDELT2 and CUNIT1/CUNIT2, and I’ll also check HelioviewerCompositeImage.php so screenshots and movie frames handle CDELT2 consistently.
The goal will be to keep the current behavior unchanged for standard square-pixel datasets such as AIA/HMI/EUI, and only enable the new logic when the image has anisotropic WCS scale, for example CDELT1 != CDELT2.
I’ll prepare this in a dedicated branch and share the approach before going too far with the implementation.