Conversation
jsantell
left a comment
There was a problem hiding this comment.
Great work! This will be valuable to have as glTF matures and as the renderers we are interested in change subjectively, and as we improve our own rendering, it'll be great to have a log of the deltas.
Other note, I think we could use something like a small README in a few dirs (src/test/fidelity, test/fidelity or maybe just test/) as the project grows. Something that I'm curious about, for a contributor, are these any actionable steps they should take when submitting a PR? What do I do with the information of a delta? Or is this more only for our infrastructure, and we will take care of interpreting what these deltas mean?
| }, | ||
| plugins, | ||
| onwarn, | ||
| }, |
There was a problem hiding this comment.
Build times are already longer than I'd prefer, I don't think we need to rebuild the image comparison on every change during development.
Current build times:
time npm run dev
> @google/model-viewer@0.0.7 build /home/jsantell/Dev/model-viewer
> tsc && rollup -c
./lib/model-viewer.js → ./dist/model-viewer.js...
(!) Circular dependency: lib/model-viewer-base.js -> lib/three-components/Renderer.js -> lib/model-viewer-base.js
created ./dist/model-viewer.js in 2.5s
./lib/test/index.js → ./dist/unit-tests.js...
(!) Circular dependency: lib/model-viewer-base.js -> lib/three-components/Renderer.js -> lib/model-viewer-base.js
created ./dist/unit-tests.js in 1.9s
./examples/dependencies/index.js → ./examples/built/dependencies.js...
created ./examples/built/dependencies.js in 694ms
real 0m10.352s
user 0m18.311s
sys 0m0.663s
There was a problem hiding this comment.
Unintentional for it to rebuild on every change. Will fix if I see it doing that locally. But, the watch files are configured as:
include: '{lib/test/fidelity/**,lib/third_party/**}'
So it shouldn't be doing that 🤷♂️
As far as build times are concerned, we should always strive to reduce them. But, this item should only build once unless it is being actively dev'd on.
There was a problem hiding this comment.
Confirmed, it only builds these new targets when I change files that correspond to the configuration.
rollup.config.js
Outdated
| output: { | ||
| file: './dist/image-comparison-app.js', | ||
| sourcemap: true, | ||
| format: 'umd', |
There was a problem hiding this comment.
I don't think we gain anything from UMDifying these builds
| "resize-observer-polyfill": "^1.5.0", | ||
| "rimraf": "^2.6.2", | ||
| "rollup": "^0.66.0", | ||
| "rollup-plugin-cleanup": "^3.0.0-beta.1", |
There was a problem hiding this comment.
With these new dependencies, I can definitely see the image comparison being a separate (in repo?) module in the future
There was a problem hiding this comment.
Yeah, probably. But, I think it should probably bake a bit before we consider splitting it out into its own thing.
src/test/fidelity/common.ts
Outdated
| for (let y = 0; y < height; ++y) { | ||
| for (let x = 0; x < width; ++x) { | ||
| const index = y * width + x; | ||
| const position = index * 4; |
There was a problem hiding this comment.
I don't think COMPONENTS_PER_PIXEL should be a constant (IMO one of the few things that can get away with being a magic number in some contexts, e.g. 255) but should be consistent
There was a problem hiding this comment.
Something to think about, but implicit meaning is almost always worse for readability. 255 at least has the context that a Uint8ClampedArray only holds uints in the range 0..255. 4 can't even say that much.
| `"${slug}/${key}" @ threshold ${threshold}`; | ||
| const percentage = `${(delta * 100).toFixed(2)}%`; | ||
|
|
||
| if (delta > ALERT_THRESHOLD) { |
There was a problem hiding this comment.
Should this be Math.abs(delta)?
There was a problem hiding this comment.
(and "decreased" on the next line changed)
There was a problem hiding this comment.
No, because it's only bad if the delta is positive. Unless I flipped things around somewhere by accident... either way, the intended behavior is sign-dependent.
There was a problem hiding this comment.
Oh, right.. a decrease is good?
I might restructure so the code is (very bad pseudo-code and wording):
if (delta > ALERT) alert
else if (delta > 0) warn('the sources are more different');
else "great! the two sources are less different"
There was a problem hiding this comment.
Oh, right.. a decrease is good?
Negative deltas = more similarity than before
scripts/compare-fidelity-results.js
Outdated
| comparisonConstraints} decreased by ${percentage}!`); | ||
| } else if (Math.abs(delta) > 0) { | ||
| const changed = | ||
| delta > 0 ? 'decreased' : delta < 0 ? 'increased' : 'changed'; |
There was a problem hiding this comment.
The third case seemed odd in code, although as I wrote it up it makes sense: delta==0, so changed='changed', so the output text is ".. changed by 0.00%".
The code would be clearer if instead of 'changed' this was 'didn''t change', maybe.
There was a problem hiding this comment.
Oh, yeah, this is vestigial actually. Re-reading, the third condition can never be reached (a pre-condition of this path is that delta is not 0). Originally, it was logging every delta (even 0%), and I thought it was too noisy. I'll just remove the third condition.
src/test/fidelity/common.ts
Outdated
| const position = index * 4; | ||
| const delta = | ||
| colorDelta(candidateImage, goldenImage, position, position); | ||
| const bool = (delta < thresholdSquared ? 1 : 0) * 255; |
There was a problem hiding this comment.
Is bool short for Boolean, or something else?
There was a problem hiding this comment.
Yes, it is short for boolean. Will fix.
There was a problem hiding this comment.
(originally shortened because it overlaps w/ the TypeScript type of the same name)
| this.candidateContext = candidateCanvas.getContext('2d'); | ||
| this.goldenCanvas = goldenCanvas; | ||
| this.goldenContext = goldenCanvas.getContext('2d'); | ||
| this.booleanCanvas = booleanCanvas; |
There was a problem hiding this comment.
boolean (as in booleanCanvas) feels like a type, rather than a comparison algorithm - although I think you are referring to the comparison algorithm. Maybe a different name that'd be more descriptive?
There was a problem hiding this comment.
Good call. Open to suggestions. I'll try to think of a better name.
There was a problem hiding this comment.
Naming's hard.
The goal is to mark pixels that differ, without shading according to the amount of difference (which the deltaCanvas does), right?
Making it longer might help.. booleanComparisonCanvas, or comparisonAsBooleanCanvas (vs comparisonAsGradient, for the currently delta, maybe).
There was a problem hiding this comment.
Or just toss a comment on the variable declaration, that'd work too.
There was a problem hiding this comment.
We decided to change this to blackWhite* throughout
test/fidelity/README.md
Outdated
| are intend to compare to include: | ||
|
|
||
| - [iOS Quick Look](https://developer.apple.com/arkit/gallery/) | ||
| - [Filament GLTF Viewer](https://github.com/google/filament/blob/master/samples/gltf_viewer.cpp) |
There was a problem hiding this comment.
nit: I think the preferred capitalization is "glTF" (even when in a title): https://www.khronos.org/gltf/
test/fidelity/pbr-spheres/index.html
Outdated
| <li>Top left: metallic 1, specular 1, roughness 0</li> | ||
| <li>Top right: metallic 1, specular 1, roughness 1</li> | ||
| <li>Bottom right: metallic 0, specular 0, roughness 0</li> | ||
| <li>Bottom left: metaalic 0, specular 0, roughness 0</li> |
|
Nice, I dig the |
|
@jsantell in response to your questions, I have added a brief blurb on analyzing Travis build results to our wiki: https://github.com/GoogleWebComponents/model-viewer/wiki/Understanding-Travis-builds |
<model-viewer>fidelity testing proposalThis change proposes a regime for measuring, analyzing and comparing the fidelity of renders produced by
<model-viewer>and renders produced by selected reference model viewer implementations, as well as aggregating analyses in order to track significant changes over time.Highlights of the change include:
<model-viewer>npm run check-fidelityreports the current working tree's fidelity relative to configured referencesnpm run compare-fidelity $GIT_REFreports the fidelity of a Git ref, announcing notable changes or regressions compared to the current working treenpm run check-fidelityis now run at the endgh-pagesbranch as it is deployedTODO
Potential future work
Examples
npm run check-fidelitynpm run compare-fidelity $SOME_REFcheck-fidelityFixes #289