frontend version: a588672

issue 1:
the gap of axis label needs to be larger

update: this issue is prominent in the electron app which uses 1280x720(?) as default size.

Without resizing the window but reconfiguring the layout, the issue becomes less prominent.

If we maximize the window (using MBP 13") and reconfigure the layout before opening any images, the issue is less prominent.

With the same electron app on iMac using its default window size, the gap is larger:

Maybe this is also an issue of hiDPI? Or the resolution of the imageViewer panel?

issue 2:
if coordinate transform is applied (attached is from native to galactic), y tick label is no longer rotated by 90 degree.

imageViewer:

• Need to show velocity, frequency, and Stokes of the current frame somewhere (integrated in the cursor info bar, maybe?).
  Format for velocity is like "%.3f km/s, LSRK / Radio, Q". Here "LSRK" can be read from the header keyword "SPECSYS", while "Radio" can be read from the header keyword "VELREF". "Q" indicates the Stokes parameter of the current frame. Format for frequency is like "%.3f MHz, LSRK, Q", where "LSRK" can be read from the header keyword "SPECSYS"
• as more information is shown in the cursor info bar, we may need a two-line bar by default.

Current plot options for displaying a stepped graph (histogram), point cloud or line graph are needlessly complicated. The two options "draw as points" and "interpolated" should be replaced by a single dropdown or a button group.

Suggested nomenclature for the three options: "Stepped", "Points", "Curve" (or "Line")

Markers (or their click handler div) are shifted in firefox, meaning you have to click on them while hovering slightly to the right of them. Might be related to the click handler div's padding.

during the animation, the boundary values for color mapping seem to be locked to the frame just before the start of animation so that some frames are all white (saturated).

During the animation, the per-frame histogram is not updated accordingly.

UPDATE: if fps is low (e.g., 1 fps with good internet speed, histogram does update and raster rendering works as normal)

Demo: https://youtu.be/JmalQwCPC5A

Currently, the file browser is implemented as a BlueprintJS Dialog. While the styling is somewhat consistent with the floating windows, the dialog should also be wrapped in a react-rnd component, to allow resizing and dragging.

For a frame containing masked pixels, cursor info should display those masked pixels as "masked", rather than 0 or some other numbers (e.g. -1.02).

This is seen in the "desktop" version. When pressing shift+space to place the cross, sometimes there is an position offset between the cross and the cursor position. This is not seen in the server version with chrome.

testing app: http://alma.asiaa.sinica.edu.tw/_downloads/CARTA-ASIAA-1-Dec-2018.dmg (with electron 4.0.0)

update: the desktop version seems to place the cross at the pixel center of the pixel pointed by the cursor, not right at the cursor position.

when animating between frames with different dimensions, the playback controls shift up and down. This makes it tricky to pause playback, as the buttons move.

The position of the cursor should be displayed on the image viewer overlay when the cursor is frozen. Something similar to this: (from IDIA tech demo)

The coordinate system should remain the same when new image is loaded as new frame.
To reproduce:

1. open orion_12co_hera.hdf5
2. open supermosaic.10.hdf5 as new frame
3. use animator to switch back to orion
4. check the gridline

• Wording around opening a new frame is confusing, and should be changed.
• Menu entries for features that have not been implemented yet should be disabled.
• Placeholder widgets should be removed
• Menu entry for "Controls and shortcuts" should be functional

frontend version: f6daeb9, tested with MBP

to reproduce this issue:

1. open J2000_test.hdf5
2. change the coordinate system from "native" to "galactic"
3. reopen J2000_test.hdf5 (not append image)
4. now the coordinate system of the grid line is still "galactic" which may be okay (ideally maybe we should reset it to "native")
5. change the coordinate system from "galactic" to "native" (should be FK5) and we see

with this snapshot version taken on dec 11 (http://alma.asiaa.sinica.edu.tw/_downloads/CARTA-v1.0-beta1.dmg), sometimes (no sure how to reproduce it exactly but it does happen) the file name becomes "download" and no image is saved. In normal case, it is its image name plus time tag and image can be saved.

Please add "#" to the second row ("x y" --> "# x y")
Please add pixel coordinate and world coordinate of the profile taken at.
Please add the labels of horizontal and vertical axes.

Example header is like (from casaViewer)
#title: Spectral profile - HD163296_CO_2_1_zoom.image-raster
#region (world): Point[[17:56:21.289, -21d57m22.221]]
#region (pixel): Point[[89, 89]]
#coordinate: world
#xLabel: radio velocity [km/s]
#yLabel: [Jy/beam] Mean

Based on newer design choices, #7 needs to be reverted.

DS9's log scaling function is described here: http://ds9.si.edu/doc/ref/how.html
We currently use a similar approach, but don't have an adjustable parameter. The "a" parameter should be introduced (possibly called "alpha"?) and shader code adjusted

frontend version: f6daeb9
It appears that the click-to-center pan action suffers from probably hi-dpi issue (found this with my MBP).
Below is before clicking the orange pixel.

We expect to see the orange pixel is centered to the axis border box. But we see

The position is off. And even higher zoom level, the offset is much prominent.

I am not sure if zoom using a hi-dpi screen has similar issue. Could you have a look too?

The line plot component's zooming and panning functionality stops working as soon as no data is displayed in the plot.

This can be replicated in a number of ways:

• Load an image with all-NaN data
• Zoom or pan the plot until no data is within the field of view.

The only way to adjust the zoom at this point is to reset the range (double clicking or clicking on the reset range button).

• The center of the bottom left pixel should have coordinates (0, 0), rather than the DS9 approach (1, 1)
• The cursor value seems to be offset from the pixel center
• Spatial profiles should be consistent with the image view in terms of pixel coordinates

Colors need to be adjusted in dark mode to ensure that ticks and labels can still be easily viewed.

Probably we need a wider window for the last shortcut.

frontend version: f6daeb9 (tested with my MBP)
I believe I am seeing things here. It appears that the cursor coordinate has precision issue.
The following is a demonstration with a model image intended for this kind of test. The orange pixel center should be located at RA=00:00:00.0000, Dec=30:00:00.0000 as indicated by the grid lines. However, we see the cursor coordinates have some offsets.

The offset is visualized by the following.

It appears that the issue here is not only for very small scales. With supermosaic image, I think we have same issue.

Could this be due to error propagation of the coordinate transformation from pixel to world?

AST config. options:

• if it is RA/DEC, use sexagesimal format by default, rather than in degree format.
  (e.g., R.A. = 12h:23m:43.234s, Dec = -34d:35m:23.123s)

• if it is galactic coordinate, use degree format by default
  (e.g., GLON = 23.123 degree, GLAT = -5.234 degree)

• "WCS(a, b)" in the cursor info bar should follow the above two rules

• default format for "Numbers" as "d.5"

• Overlay settings -> Global -> Color (not functional; this is supposed to change the color of ticks, grid, label, etc. in one shot?)

using IDIA carta with frontend version: b9e44e2

To reproduce:

1. open orion_12co_hera.hdf5

2. we should see correct cursor coordinate and tick label coordinate
   

3. now change the coordinate system from FK5 to galactic

4. issue 1: the tick label format should be changed to degree automatically.
   

5. issue 2: by manually changing the format to degree, the tick labels (incorrect) are not consistent with the cursor coordinate which should be the correct one.
   

6. similarly, with supermosaic.10.hdf5, changing from galactic to FK5 results in the same issue.

Sometimes, menu items aren't registered when clicked on, because the clicks are being intercepted by something with a higher z-index. The user then has to click on the items once to make them focussed, and once again to actually "click" them.

The video shows this odd behavior.
https://www.youtube.com/watch?v=774bXm-IXlM

The test is done with the dev-viewer, chrome, and MacBook Pro using track pad. Frontend version = 933a9e0
The beginning of the video demonstrates that the pointing of the track pad should work precisely. But while clicking on the histogram, the min red line doesn't update to the position where left-click is issued.

Also tested with iMac using Magic Mouse, it works properly...

This issue becomes prominent when viewing small images, as demonstrated by the attached images.

• Spectral profile plots aren't resized correctly when the window size changes (although they are resized correctly when the drag handles are used)
• Spectral profile plots don't seem to use the correct pixel ratio

GoldenLayout drag borders aren't visible, because dragged components aren't a child of the app component

The channel indices in the animator collide when the panel is narrow and the total number of channels is too large. Attached is an example viewing a cube with a 7680-channel cube on my laptop.

Perhaps we can improve this by just showing the first and the last channel indices. Users can estimate where to click to jump to a certain channel with the help of the channel index below the slider.
Or, the indices can be generated in a more smart way with the consideration of the widget width.

Both spectral and spatial profilers shoud:

• display the value of the cursor along the x axis somewhere in the widget
• display the value of the graph itself at the cursor location somewhere in the widget (by looking up data efficiently
• display the mean and RMS values somewhere in the widget when the "show RMS" toggle is checked

In the xyz profile plots, it seems that the step is aligned to the left edge, not center. Naively aligning to the center is better. Any thoughts?

• Zoom speed is very slow in firefox. Possibly the scroll wheel event's delta factor isn't being taken into account.

frontend version: b9e44e2
In overlay setting/grid, if custom gap is toggled, the coordinate grid is disappeared.

Currently the same icon as the customize dialog for overlay, which may create confusing.

This issue will happen whenever keeping zooming out. In the render area, user can keep zooming out unlimitedly. This action will cause that all objects on the canvas are gone, and system crash in some case. Another the functionality of zoom in also has no limitation.

frontend version: f6daeb9, tested with MBP

Only the first quadrant of a pixel provides correct both frontend and backend profiles. Others do not.

Please refer to the attached movie to demonstrate this issue. Please focus on the intersect at (6000, 5000). The position moves in that pixel when changing zoom levels. The test image is LMCq.hdf5.

https://youtu.be/ABrDFAMbG1I

for x and y profilers, the default file name is like
S255_IR_sci.spw29.cube.I.pbcor.fits-X-profile-2018-12-11-12-38-2
"X", or "Y" is indicated.

for z profiler, the default file name is like
S255_IR_sci.spw29.cube.I.pbcor.fits-unknown-2018-12-11-12-39-35, if we use default axis (e.g., frequency). If "use WCS values" us disabled, "unknown" will be replaced by "Z".

"unknown" is also seen in the histogram tsv output name.

• Show correct coordinate when using TSV output from spectral profiler
• Show correct coordinate (histogram?) when using TSV output from histogram

frontend version: 8f455e0 (ASIAA backend)

The test images can be accessed via (400MB+)
https://drive.google.com/file/d/1LWa6dkkFrLjqqeq88TBViiIiWqFjMKSW/view?usp=sharing (400MB+)
https://drive.google.com/file/d/17_idrAMvtLbMhNapAGguzi7tB_vai1wb/view?usp=sharing (small one)

With these test images, the cursor coordinate is shown incorrectly. R.A. should not have a negative hour.

Update:
it appears that crossing the R.A.=12h line will produce this issue. When R.A. < 12h, the cursor R.A. is correct, not for R.A. > 12h.

Update 2:
crossing R.A.= 0h will also have this issue. Try "J2000_test.hdf5"

Need to add basic zoom in / zoom out buttons to the quick access toolbar. Their tooltip should indicate that the user can scroll to zoom in.

To reproduce (found from testers feedback):

1. open J2000_test.hdf5
2. append orion_12co_hera.hdf5
3. in animator, click "Frame" radio button
4. open cube_x419_z101_68MB.hdf5 (so the previous two are closed)
5. now in animator, there is only "Channel" radio button and is not checked. So hitting "play" results in nothing.

Color map thumbnails are all blank when viewed in webkit-based browsers.

Resizing individual widgets seems to work fine, but sometimes the image view doesn't resize correctly when resizing the entire window.

when viewing a cube with a small number of channels, some redundant indices show up as shown in the attached image. Note that the Stokes axis does not have this issue.

There are a number of enhancements that the line plot component needs:

• Zooming in Y and XY
• Horizontal markers (e.g. for mean values)
• Rectangular markers (non-interactive) (e.g. for RMS indicator)
• Optional callback for tick formatting
• Options for showing/hiding X and Y labels
• Line/point options for data

title -> font size to ~18. 24 is a bit too large.
numbers -> font size to ~12. 10 is a bit too small.

please rotate y-tick label by 90 degree so that y-axis label can be displayed independent of the precision of y tick numbers.

We are almost there! Well done!

Now with "Toggle labels" button on the image viewer when hovering on, the GUI state is not sync'd. When "Toggle labels" is False, the two "visible" are still True in the overlay settings.

I suggest we rename "Toggle labels" to "Toggle labels and tick numbers" or something similar to be consistent with what it actually does. We will need to make sure the UI state is sync'd.

Do we really need "Toggle labels" button? Not sure this is a commonly used action to turn off labels and tick numbers. We can keep it for now and listen to what users think.

frontend version: c626cb2

the saved png image is not consistent what we see on screen.
On screen:

Saved: