Skip to content

Conversation

@j9liu
Copy link
Contributor

@j9liu j9liu commented Jun 17, 2021

Fixes #9390.

The UNPACK_COLORSPACE_CONVERSION_WEBGL flag was not set to NONE as specified in the glTF documentation.

When the Sandcastle from the issue is copy pasted into a local session, it should now look like this. The spheres across each row are identical.

image

cc @ebogo1 @shehzan10

@cesium-concierge
Copy link

Thanks for the pull request @j9liu!

  • ✔️ Signed CLA found.
  • ❔ Unit tests were not updated.
    • Make sure you've updated tests to reflect your changes, added tests for any new code, and ran the code coverage tool.

Reviewers, don't forget to make sure that:

  • Cesium Viewer works.
  • Works in 2D/CV.
  • Works (or fails gracefully) in IE11.

@lilleyse
Copy link
Contributor

The change seems good for glTF but it could impact rendering of non-glTF images such as imagery on terrain, textured polygons, or billboards. You might notice something if you compare sandcastle examples on this branch vs. master (or maybe not).

The safe thing to do would be to add an option to Texture called skipColorSpaceConversion that only Model.js sets to true.

CC @ptrgags @sanjeetsuhag for the Model.js rewrite

@j9liu
Copy link
Contributor Author

j9liu commented Jun 18, 2021

@lilleyse - just pushed some changes, is this better?

@j9liu
Copy link
Contributor Author

j9liu commented Jun 21, 2021

@lilleyse - what do you think of these changes? I haven't found a workaround for the HTMLCanvasElement situation yet, but I'll keep looking.

I changed the structure of the options in the createImageBitmap and loadImageFromTypedArray functions, so if we keep the changes, I will need to adjust one of the unit tests because the change is causing it to fail.

@j9liu j9liu changed the title Ignore colorspace information in texture images that interferes with glTF rendering Add option to ignore colorspace information in texture images Jun 22, 2021
crossOrigin,
deferred,
flipY,
skipColorSpaceConversion,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did a global search for createImage and noticed that some terrain and imagery tests require updates. See ArcGisMapServerImageryProviderSpec.js and others examples like below - the new parameter needs to be added.

          Resource._DefaultImplementations.createImage(
            request,
            crossOrigin,
            deferred,
            true,
            true
          );

expect(window.createImageBitmap).toHaveBeenCalledWith(blob, {
imageOrientation: "none",
premultiplyAlpha: "none",
colorSpaceConversion: "default",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excellent tests throughout!

* or an object with width, height, and arrayBufferView properties.
*
* @param {Object} source The source {@link ImageData}, {@link HTMLImageElement}, {@link HTMLCanvasElement}, or {@link HTMLVideoElement},
* @param {Object} options Object with the following properties:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the sake of API symmetry we should also make the same changes to CubeMapFace.prototype.copyFrom.

@lilleyse
Copy link
Contributor

@j9liu thanks for the updates, they look really good overall. Just a few small things left and this PR should be ready to go.

@j9liu
Copy link
Contributor Author

j9liu commented Jun 23, 2021

@lilleyse - I think I addressed all your comments; let me know if I missed anything!

Also, I noticed that these two tests fail when I run them -- should I look into them? They were failing before I made the major changes to Texture and Resource, so I'm not sure if it is related to what I did.

image

*
* @param {Context} context The context to use to create the cube map.
* @param {Object} urls The source URL of each image. See the example below.
* @param {Boolean} skipColorSpaceConversion If true, any custom gamma or color profiles in the images will be ignored.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* @param {Boolean} skipColorSpaceConversion If true, any custom gamma or color profiles in the images will be ignored.
* @param {Boolean} [skipColorSpaceConversion=false] If true, any custom gamma or color profiles in the images will be ignored.

Comment on lines 224 to 229
Resource._DefaultImplementations.createImage(
request,
crossOrigin,
deferred
deferred,
true,
true
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I should have been clearer about this. The only functions that need to be updated are those that were already passing in the optional parameters like here. Since createImage now takes 6 parameters code like below needs to be changed

          Resource._DefaultImplementations.createImage(
            request,
            crossOrigin,
            deferred,
            true,
            true
          );

changes to

          Resource._DefaultImplementations.createImage(
            request,
            crossOrigin,
            deferred,
            true,
            false,
            true,
          );

if (typeof sources.positiveX === "string") {
// Given urls for cube-map images. Load them.
loadCubeMap(context, this._sources).then(function (cubeMap) {
loadCubeMap(context, this._sources, false).then(function (cubeMap) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fine to use the default value here

Suggested change
loadCubeMap(context, this._sources, false).then(function (cubeMap) {
loadCubeMap(context, this._sources).then(function (cubeMap) {

@lilleyse
Copy link
Contributor

Also, I noticed that these two tests fail when I run them -- should I look into them? They were failing before I made the major changes to Texture and Resource, so I'm not sure if it is related to what I did.

It looks like the tests pass in master so I think it's a regression in this PR. There's a good chance that once #9624 (comment) is addressed they will be fixed.

@j9liu
Copy link
Contributor Author

j9liu commented Jun 24, 2021

@lilleyse - sorry for the misunderstanding! I reverted the changes. You were right, the fix for the missing parameter made those two tests pass.

@lilleyse
Copy link
Contributor

I push a commit to revert one last test: 99f7a7b

Otherwise this looks good. I ran tests locally, tested TextureEncodingTest.gltf and TextureEncodingTest.glb with ImageBitmap enabled and disabled, and spot checked sandcastle examples.

Thanks @j9liu!

@lilleyse lilleyse merged commit 4fb9fbb into master Jun 24, 2021
@lilleyse lilleyse deleted the texture-encoding-gltf-bug branch June 24, 2021 17:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

TextureEncodingTest.gltf is different from expected result

4 participants