You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
The render configuration widget and the contour rendering dialog have a histogram plot showing the per-channel histogram by default. Optionally users may switch to per-cube mode to see a histogram derived using the entire cube.
When a 4D cube with multiple Stokes (eg Stokes IQUV) is loaded in CARTA and we request to see the per-cube histogram of Stokes I, we will see the backend starts to deliver partial per-cube histogram to the frontend. Once it is done, if we use the animator to switch to Stokes Q, for example, we will see the "Histogram" dropdown switches to per-channel (as expected) but the backend starts to calculate the per-cube histogram of Stokes Q and once it is finished, the backend then calculates the per-channel histogram of the Stokes Q in the image viewer.
To Reproduce
Steps to reproduce the behavior:
load a 4D cube with multiple Stokes and enable the JS console
request per-cube histogram
use the animator to switch to Stokes Q and monitor the JS console
we should see per-cube histogram being calculated first, then the per-channel histogram is calculated.
When the per-cube histogram is calculated we will see nothing happens from the GUI. But if we request a per-cube histogram when the backend is busy on calculating the unexpected per-cube histogram, we will see the progress bar shows up repeatedly. Sometimes this results in incorrect clip bounds (I saw 0,1).
Expected behavior
The expected behavior in step 4 should be that only the per-channel histogram is calculated. I guess the root cause is the logic behind SET_IMAGE_CHANNELS (where we can set a Stokes value via stokes parameter) and SET_HISTOGRAM_REQUIREMENTS (where we can request a per-channel or a per-cube histogram via region_id parameter)
Screenshots or videos
This is a screenshot of the JS console. The last REGION_HISTOGRAM_DATA carries the per-channel histogram. All the other REGION_HISTOGRAM_DATA before carry the unnecessary per-cube histogram data.
Platform info (please complete the following information):
OS: only tested with macOS Monterey
Browser: chrome
Version 97.0.4692.71
Additional context
N/A
The text was updated successfully, but these errors were encountered:
@kswang1029 In the contour rendering dialog, if we select per-cube histogram and then switch to another Stokes. The default is still per-cube histogram for another Stokes, not per-channel histogram, this behavior is not the same as that in the render configuration widget. Should it be changed? If so, I guess the contour rendering dialog in the frontend also needs to be fixed. The default histogram for the new Stokes is always per-channel histogram.
Describe the bug
The render configuration widget and the contour rendering dialog have a histogram plot showing the per-channel histogram by default. Optionally users may switch to per-cube mode to see a histogram derived using the entire cube.
When a 4D cube with multiple Stokes (eg Stokes IQUV) is loaded in CARTA and we request to see the per-cube histogram of Stokes I, we will see the backend starts to deliver partial per-cube histogram to the frontend. Once it is done, if we use the animator to switch to Stokes Q, for example, we will see the "Histogram" dropdown switches to per-channel (as expected) but the backend starts to calculate the per-cube histogram of Stokes Q and once it is finished, the backend then calculates the per-channel histogram of the Stokes Q in the image viewer.
To Reproduce
Steps to reproduce the behavior:
When the per-cube histogram is calculated we will see nothing happens from the GUI. But if we request a per-cube histogram when the backend is busy on calculating the unexpected per-cube histogram, we will see the progress bar shows up repeatedly. Sometimes this results in incorrect clip bounds (I saw 0,1).
Expected behavior
The expected behavior in step 4 should be that only the per-channel histogram is calculated. I guess the root cause is the logic behind SET_IMAGE_CHANNELS (where we can set a Stokes value via stokes parameter) and SET_HISTOGRAM_REQUIREMENTS (where we can request a per-channel or a per-cube histogram via region_id parameter)
Screenshots or videos
This is a screenshot of the JS console. The last REGION_HISTOGRAM_DATA carries the per-channel histogram. All the other REGION_HISTOGRAM_DATA before carry the unnecessary per-cube histogram data.
Platform info (please complete the following information):
Additional context
N/A
The text was updated successfully, but these errors were encountered: