Difference in textures' images after import ( SketchUp SDK 23.0.397.0 vs 2024.0.484.0)

Developers SketchUp SDK
, , , ,
1

After updating SketchUp SDK from 23.0.397.0 to 2024.0.484.0 textures were changed.

After import all the data from sketchup file I’m trying to save appropriate textures’ images to files via next code:

SUTextureRef texture = SU_INVALID;
const auto get_texture_result = SUMaterialGetTexture(i_su_material, &texture);
if (get_texture_result != SU_ERROR_NO_DATA) {
  if (get_texture_result != SU_ERROR_NONE)
    throw std::runtime_error("unable to get texture from material");
  MSUString texture_file_name;
  if (SUTextureGetFileName(texture, &texture_file_name.Access()) != SU_ERROR_NONE)
    throw std::runtime_error("unable to get material name");
if (SUTextureWriteToFile(texture, i_file_name) != SU_ERROR_NONE)
  throw std::runtime_error("unable to store");

But results are different between different versions of SDK. Output images are visually similar but if I’m trying to compare them pixel-wise (each channel separately) difference can be more than 10 units from 255 for color channel.

Is there any way to prevent changes in behavior? Are there any obvious reasons for such changes in behavior?

Here is example of different images (sorry, new user only one image can be uploaded).

diff
diff1920×929 98.9 KB

2

Hmm looks like the texture is recompressed, did you tried SUTextureWriteOriginalToFile ?

3

Thanks a lot - it helps :slight_smile:

4

Hm, looks like appropriate methods have different behavior:

Capture
Capture1088×381 315 KB

At least some texture information was lost. Two results with exactly the same code, the only difference - SUTextureWriteOriginalToFile vs SUTextureWriteToFile

5

SUTextureWriteOriginalFile will (or at least should) write an original (embedded) image bytes, in your case it looks like the material has been colorized (check SUMaterialGetType and SUMaterialGetColorizeType).

I have no idea why there is a difference between v23 and v24, maybe the underlying image processing SDK has been changed. Maybe try to export it (from both and compare) as lossless format like PNG.

6

Check the official SketchUp API Issue tracker:

If it is not listed, please open a new issue report with reproducible code snippet.

7

In latest SketchUp I found a flag that makes behavior exactly as same as in my workflow:

  • if flag is “enabled” (default behavior during opening file) - behavior looks similar to SketchUp API 2023
  • if flag is “disabled” - behavior looks similar to SketchUp API 2024

As you can see “color”/texture is changed:

flag
flag1920×1896 208 KB

Don’t you know what the sense of this flag/checkbox is? Is there any flag in SketchUp API to keep old behavior?

8

I’m curious, where is this ‘flag’?

9

It refers to the “Reset Color” button on the Edit Material dialog.

I do not see any specific function in the C API with regard to “resetting” a material’s texture.

@tt_su ?

1 Like
10

Have you tried the latest version of the C SDK ?

11

You mean 24.0.553? if so - no, didn’t try it yet. Should I? Can it help?

12

First of all, you reported problems with an old SDK version, viz …

The SDK core code is at a newer version, and all changes would be made from that “milestone”.

Yes, you should try it and verify that the issue still exists. If the problem was a regression bug, it might have already been fixed in the next (or later) SDK versions.

If the problem is still present in the latest version, then as said, please log a report in the official API issue tracker.

13

First of all, you reported problems with an old SDK version

It wasn’t old when it was reported at the first time as I remember, but nevertheless appropriate problem exists in the latest SDK version (2024.0.553.0)

Will report it to official API issue tracker, thx

14

Perhaps. But, 24.0.553 was released in MAY. You opened this topic in JULY.
But I have no idea when you really noticed the problem.

Also, the SDK build for 24.0.594 is due out soon if it has not yet been posted.