Using subPixelRoundingForTransparency to test a tile boundary issue

[bdrichards]

I need a little help including subPixelRoundingForTransparency in viewer options, here is a snippet of my options list. Is the subPixelRoundingForTransparency referenced properly? There isn't an example of syntax that I could find anywhere:

            . . . 
            zoomPerSecond: 0.2,
            subPixelRoundingForTransparency: { '*', SUBPIXEL_ROUNDING_OCCURRENCES.ALWAYS },
            tileSources: {
            . . . 

Reason for testing this: we have encountered the "tile boundary visible" issue (at all zoom levels, image below). The details need explaining, but in general: deepzoom tile sets generated by Image Composite Editor (ICE), file_type = PNG ( no known transparency regions within tile), tile_overlap = 1, tile_size = 256, Windows 7 system and occurs in all browsers tested, OSD versions prior to 2.4 do not display the issue. Thought we would try this option to see if it resolves. We tested setting tile_overlap and tile_size combinations, but same result. HERE is link to image in OSD viewer

[pearcetm]

If you build from master and use drawer: 'webgl' (which is the new default) are the tile boundaries fixed?

[bdrichards]

@pearcetm ,Thanks for your response.
I do not build from master. I just use the already built versions of openseadragon.js
Can the "drawer" be set in viewer options or in the js file itself?

[pearcetm]

I do not build from master. I just use the already built versions of openseadragon.js

The new WebGL drawer was introduced in #2310 which isn't part of a release yet, so you'd have to build it yourself to try it out. A main motivation for using WebGL was to avoid tiling artifacts like this. If you're interested in doing so, it is as easy as cloning the repository and following the contributing guide to see how to build a local copy.

In terms of your current situation, PNGs are always treated as potentially transparent, which causes tiling issues like you're seeing. One thing you can try is overriding this by overriding TileSource.hasTransparency to always return false like so: viewer.world.getItemAt(0).source.hasTransparency = ()=>false. This might help. It at least partially helps when run in the debugger in the example you linked. If it is run before the rendering happens at all it might work even better. However this is a total hack and using the most recent version with webgl would be a more robust solution I think.

[pearcetm]

Can the "drawer" be set in viewer options or in the js file itself?

You can select the drawer in the viewer options (e.g. drawer: 'webgl' or drawer: 'canvas') but only if you build from master at this point.

[bdrichards]

Thank you for the instruction for building a local master. I will give it a go sometime this weekend. But, does the subPixelRoundingForTransparency come into play for eliminating the tile boundary? Also, why does the issue not occur with OSD v2.3 and earlier?

[pearcetm]

I'm not sure exactly why you aren't seeing this in v2.3 and earlier, but I would guess that code was added at some point that improved drawing of some images but caused other issues like this one too.

I was able to use your example page (thanks for providing that link!) and the debugger console to figure out a couple of fixes for you (which don't require building from master).

First, your instinct that subPixelRoundingForTransparency is important is correct. The viewer thinks that your image has transparency (even though it doesn't) because you're using PNG images as your tiles.

Setting subPixelRoundingForTransparency: subPixelRoundingForTransparency: OpenSeadragon.SUBPIXEL_ROUNDING_OCCURRENCES.ALWAYS fixes the problem.

Another way to fix it is to tell the viewer that the tile source does NOT have transparency:
viewer.addHandler('open',()=> viewer.world.getItemAt(0).source.hasTransparency = ()=>false )

The latter option is more of a hack though, I'd go with the former. It looks like you were just missing the OpenSeadragon. prefix before SUBPIXEL_ROUNDING_OCCURRENCES in your config options.

[bdrichards]

Thank you for the suggestions!. Yes, setting the subPixelRoundingForTransparency: does resolve the tile boundary issues. HOWEVER, the tiles now "quiver" upon zooming. It's as if there is a severe heat-wave shimmer occurring, it disappears as the zoom event settles down. Check the example page....
So, Which is the lesser of the two effects to leave for people to view...... (or I may just drop back to v2.3something)

EDIT:
Thanks for your "hack" suggestion as well. Implementing that has removed the "quiver" in a temp implementation (what is visible in the previous link provided still exhibits the issue for a demonstration).

[pearcetm]

The quiver/shimmer you're observing is inherent to the rounding that is needed to avoid seams. See #1713 (comment) for a discussion, and #2075 for further info.

One option that is supported by the current viewer options is to only apply the subpixel rounding once animation is complete, so that it doesn't jitter during animation. However, since you don't actually have transparency, the "hack" is maybe the best way to go.

The best fix, though, is probably to use the WebGLDrawer instead - at least, once it makes it in to an official release, if you don't want to host your own version built from master.

[bdrichards]

Thanks for the update.
Sorry if using the "hack" word came across offensive, it actually is a nice, easy-to-understand temporary "workaround".
I'm attempting a local build, but step number 3 in the contributing guide says "Clone the repository". Well, that provides a barrier. Following the directions for cloning a repository gets me to a step that says: "Open git bash". Since I am on a Windows system (IIS), I have no "git bash" locally. Kind of dead in the water.
Thank you for the help, though.

[pearcetm]

No worries about calling it a “hack” - that was my term for it after all! Are you able to install https://gitforwindows.org on your windows dev environment? Having git for version control is always a good idea…

…

On Sat, Apr 13, 2024 at 8:02 PM bdrichards ***@***.***> wrote: Thanks for the update. Sorry if using the "hack" word came across offensive, it actually is a nice, easy-to-understand temporary "workaround". I'm attempting a local build, but step number 3 in the contributing guide says "Clone the repository". Well, that provides a barrier. Following the directions for cloning a repository gets me to a step that says: "Open git bash". Since I am on a Windows system (IIS), I have no "git bash" locally. Kind of dead in the water. Thank you for the help, though. — Reply to this email directly, view it on GitHub <#2514 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC7LYHIV25F7CVCQD3YWPWDY5HBSLAVCNFSM6AAAAABGE4LQKWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJTHAYDQMBWGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[bdrichards]

Thanks for the "hack"/"workaround"!
As for installing git for version control:
After spending a couple of hours installing things (node.js, npm, and git), and then enduring an urgent phone call from the college's network administrator asking what the he** I was up to, I was able to "clone the repository"!!! Turns out the virtual server they set up for me was not intended to be a development site, but is a public-facing (but firewalled) "production" site!! NOW they tell me!
Glad I spent the time identifying all of the bits and pieces, though. A couple of times in the past few years, @iangilman has graciously prompted me to formally add edits I have made to the "bookmark-Url" plugin. However, the steps provided always led to menus that did not match the instructions/steps and directions totally foreign to me, so I shied away from pursuing it (sorry @iangilman if you felt ghosted)...... I think I might be able to handle those things now.... aside: fortunately, a talented supporter here has formally made those edits into that plugin!!!!
Thanks again for the patience and instruction, we need best quality experience in place for students' practical exams in 2 weeks!
BDR

[iangilman]

@bdrichards No worries... I'm glad you're moving up the learning curve!

[bdrichards]

@iangilman
Thanks for the confidence. HOWEVER, my first repository clone was of "openseadragon.github.com" - the website, not the current master - duoh!
Now, I corrected that and cloned the current master, but get the following error trying to build (grunt is installed), any suggestions? Is there a file missing from the clone - see screen capture of files in the dir?:
"D:\Inetpub\NIC\osdbuild\openseadragon>grunt
grunt-cli: The grunt command line interface (v1.4.3)

Fatal error: Unable to find local grunt.

If you're seeing this message, grunt hasn't been installed locally to
your project. For more information about installing and configuring grunt,
please see the Getting Started guide:

https://gruntjs.com/getting-started

D:\Inetpub\NIC\osdbuild\openseadragon>"

[msalsbery]

@bdrichards

Have you done all the "First Time Setup" steps?

From CONTRIBUTING.md

1. Install Node, if you haven't already (available at the link above)
2. Install the Grunt command line runner (if you haven't already); on the command line, run npm install -g grunt-cli
3. Clone the openseadragon repository
4. On the command line, go in to the openseadragon folder
5. Run npm install

[pearcetm]

From the comment in this stackoverflow question, this error message can happen if you haven't run npm install after cloning the repository (i.e. step 5 in @msalsbery's comment above). I wonder if this would help you get past this.

[bdrichards]

@msalsbery , yes, I followed the Contributing Guide steps, but with first repository (not the intended one). Perhaps some explanation as to what "npm install" accomplishes would help in more complete understanding. Ran within the newly cloned repository and everything gets into the build!! Apparently, "npm install" module also calls "grunt" Thanks for the assistance!
...