fix: Correct the positioning for the viewport

[wayfarer3130]

Context

The sizing and positioning of the canvas was being computed incorrectly, causing the rendering to be in the wrong size/position.

Changes & Results

Added type/scale for pixel scaling mode to viewport to enable a scaling value to be used Fixed thumbnail rendering so it renders in the correct aspect ratio when provided a default canvas Fixed rendering so that it draws exactly what is provided/rendered from the vtk side Fixed viewport sizing so it is a pixel exact sizing, to prevent half pixel renders

Testing

In OHIF, use the hpScale hanging protocol to setup 1:1 display rendering Take a screen capture of the TG-18 resolution 'LN' series Open in an image editor with replicate zoom Zoom in on the image. The little squares should have sharp edges

Alternatively - view the multi purpose TG-18 1k resolution image in the 1:1 scale mode (type=SCALE, scale=1) The 5 horizontal/vertical single pixel line pairs should NOT show any moire or grayscale patterns:

Checklist

PR

• [] My Pull Request title is descriptive, accurate and follows the semantic-release format and guidelines.

Code

• [] My code has been well-documented (function documentation, inline comments, etc.)

• [] I have run the yarn build:update-api to update the API documentation, and have committed the changes to this PR. (Read more here https://www.cornerstonejs.org/docs/contribute/update-api)

Public Documentation Updates

• [] The documentation page has been updated as necessary for any public API additions or removals.

Tested Environment

• [] "OS:
• [] "Node version:
• [] "Browser:

[netlify[bot]]

✅ Deploy Preview for cornerstone-3d-docs ready!

Name	Link
🔨 Latest commit	779ef877a5e29d815494ddf4a0fd68f9c9ca85c3
🔍 Latest deploy log	https://app.netlify.com/sites/cornerstone-3d-docs/deploys/6615a6495dd752000811dc18
😎 Deploy Preview	https://deploy-preview-755--cornerstone-3d-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[wayfarer3130]

It is easier to show the positioning with the exact positions - both CSS and physical pixels: Suppose we have a 3 pixel wide image - that is, the image pixels: 0,255,0

Now, when we go to render this, we have a div element to put our canvas into which has: devicePixelRatio: 2 left CSS: 1.25 px left physical: 2.5 px width CSS: 3 px width physical: 6 px

Now, we want to see how the image pixels get rendered to the viewport. First, how much space do we have? Well, if we start with assuming we can display the entire width, then we get 6 physical pixels - BUT, the left and right edges each have a half physical pixel. So, if we want to use physical pixels only, then we need to look at the CSS view for the nearest physical pixel on the left - that is: ceiling(left edge in physical) - left edge in physical= ceiling (2.5) = 3 - 2.5 px = 0.5 px that is, the left most edge loses 0.5 physical PX Now, the width is reduced by 0.5 px, and we don't want to use any physical fractional pixels on the right, so we get: width usable = floor(width physical - fractional left) = floor(6 - 0.5) = 5.5 physical px = 2.75 CSS px

[wayfarer3130]

For the previous example, with 3 image pixels, suppose the mapping for the image pixels to canvas pixels is from the center of the image pixel, to the edge of the screen pixels - that is, the center of the canvas pixels are: -0.5, 0.5, 1.5, 2.5, 3.5 That is, the 3 image pixels are smeared across 5 physical pixels - in this case, each physical pixel has the average value of both image pixels on either side, those being:

(0 * 0.5 + 00.5) = 0 (0 * 0.5 + 2550.5) = 127.5 (255 * 0.5 + 0* 0.5) = 127.5 (0 * 0.5 + 0*0.5) = 0 That is, where we had a nice bright line down the center, we have doubled the size of it, and halved the intensity. Consider what happens if this were a single pixel line denoting a fracting in a bone. You suddenly get a line half the intensity, but quite a bit wider. Maybe that is visible, and maybe not. Certainly a lot harder to view.

This can happen in either of 2 places - the GPU rendering to the GPU canvas can do it. This needs to ensure that the offscreen canvas is exact and that the computations for positioning etc are exact.

It can also happen if the onscreen canvas mismatches the offscreen canvas.

[wayfarer3130]

@sedghi

• fixed a rendering issue with even sized viewports caused by rendering an image pixel to a physical pixel offset by a half pixel.
• fixed the issue you noticed during the in person review where the canvas size could be smaller than the div size causing the background to not be rendered for a single pixel.

[sedghi]

I started reviewing this. I don't see much improvement for the tg18-cx-2k-01.dcm

Am i doing something wrong? I'm dragging and dropping in the local example in cornerstone3D Maybe the new changes you made has affected it?

upstream (current behaviour)

You PR

[sedghi]

same also for image diff

https://github.com/cornerstonejs/cornerstone3D/assets/7490180/4a87d65a-a572-45ab-ae8e-fed38e8cc0cb

[sedghi]

Ok seems like this PR will fix the issue where device pixelRatio is float (either zoomed or differet aspect ratio)

Note: If device pixelRatio is 1.25 or 1 or anything that is not float it actually renders correctly

[sedghi]

I was updating visual tests and capturing new ones to be compared to and saw an unusual behaviour, the test is called Should be able to flip a stack viewport horizontally

Original

Flipped Horizontally

Flipped Vertically

[sedghi]

Also, it seems like the volume rendering tests show this incorrect pattern of a half bar. (I'm quite familiar with this bug, and it is related to the focal point. It has caused me a lot of trouble during the development of cornerstone3D.)

In main

In new PR:

[Max-Kharitonov]

@sedghi any updates?

[sedghi]

@Max-Kharitonov There are some issues regarding when the image is flipped and I didn't have time to look at it