-
Notifications
You must be signed in to change notification settings - Fork 597
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rendering using css transform instead of canvas transform #37
Conversation
I've just recently started working with Cornerstone, and I like the move to CSS-based transformations, which is something I had been investigating when I came across this PR. |
This is on my list to review - stay tuned (big PRs take a while for me to review) |
I've updated my PR by removing the container div called renderer and stuff related to my attempt to draw annotation. Also I've corrected the transform computation done on |
fitToWindow() ProblemI was struggling with the fitToWindow behavior because currently fitToWindow will fit and center the image displayed into the canvas, we can easily get both objects (canvas & image) size in order to do that. Now on cssTransform fitToWindow means fit and center the canvas (which has the same size as the image) into the element. Problem comes when I tried to get the element size in order to compute the scale. Element is created and managed by the final user and there is way too much ways of getting the good width and height (using offsetWidth, offsetHeight, computedStyle, getBoundingClientRect()...) depending on how web design is done (do we want to include padding, border etc...). So I think user must provide element's width and height for this to work. I also think we should not provide a default behavior like using offsetWidth/offsetHeight but force the user to compute itself the element width and height so he is totally aware of how this works and he knows it must adapt it if he change the web design. Avoiding issue tickets 'fitToWindow() won't work anymore' :) SolutionUsing viewport override on displayImage() and the now public scaleToFit() function, user can easily still have a fitToWindow behavior on image display like this : cornerstone.displayImage(element, image, {
scale: cornerstone.scaleToFit(element.offsetWidth, element.offsetHeight, image)
}); And calling fitToWindow will be done like this :
reset() problemProblem is this create a problem for the reset(), since default scale is now 1, reset() will not apply the fitToWindow behavior. To resolve that we could ask the user to successively call reset() and fitToWindow() but didn't liked that. SolutionInstead reset() will now reset the viewport into the last viewport defined by displayImage() including the override. I think it's good because it allows the user to define the 'initial viewport' and let him reset to that 'initial viewport' instead of reseting into our defined default viewport. Here is and illustrated example : //We define the initial viewport (combination of defaultViewport() and override passed as argument)
cornerstone.displayImage(element, image, {
scale: 5,
invert: true,
voi : {
windowWidth: 2048,
windowCenter: 1024,
}
});
//Initial viewport is then
//{
// scale : 5,
// translation : {
// x : 0,
// y : 0
// },
// voi : {
// windowWidth: 2048,
// windowCenter: 1024,
// },
// invert: true,
// pixelReplication: false,
// rotation: 0,
// hflip: false,
// vflip: false,
// modalityLUT: image.modalityLUT,
// voiLUT: image.voiLUT
//}
//We can modify the viewport as much as we want
....
cornerstone.setViewport( element, modified_viewport );
//will reset to the initial viewport shown before
cornerstone.reset(element); As always I've just modified the scrollzoompanwl example. |
This is a pretty old PR. While I think it's a neat spike, I'm not sure how practical it is. I would be open to looking at a revamped version of this if a good enough case could be made for the performance benefits. |
Hi.
To follow this discussion, I tried to do some modification into cornerstone to avoid some issue I was having (especially with cached rendercanvas ).
So cornerstone rendering works as follow :
- Fill a "render" canvas with same size as the image with image pixel (applying lut etc..)
- Draw this "render" canvas into the final canvas and set all transformation the image on the final canvas
What I did was :
- Fill the "render" canvas like before except this canvas is also the final canvas displayed on screen.
- Set all transformation using css.
Pro:
context.createImageData()
and ``cornerstone.storedPixelDataToCanvasImageData()` (but because a Blink bug we may have to revert it back).Con:
pointer-events
available only from IE 11.This is not a real pull request, just a place to discuss about it then we will work on it if you're interested.
I've been working with this version of cornerstone on my viewer (on development/test) and it works really great for me.
You'll see some work about annotation, this part is really on an early stage. Even if I think cornerstone should offer an API to work with annotation, I just did it for the scrollzoompanwl example. So let's not talk about it, we'll see that later on.
Also it's the only example I've been working on so others may be broken.
Here is a link to the scrollzoompanwl example.