Skip to content
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

Extremely large images (~50k range) may not load correctly, leaving artifacts or missing gaps in the image #509

Closed
Stoppedpuma opened this issue Nov 6, 2024 · 9 comments
Labels
bug Something isn't working

Comments

@Stoppedpuma
Copy link
Collaborator

Discovered last week while testing #506, slightly annoying to reproduce as Oculante likes to crash occasionally loading these images. This issue happens every once in a while.

May cause (that I'm aware of):

Artifacts that look like texture corruption or what an asset in a pixel art style game would look like
Incorrect colours
Entire gaps being missing

@B-LechCode Pinging you here for this in-case you have any ideas of what's causing this. (In the chance that you see this before I can reproduce this again with an image showing this, I'll add an image when I can reproduce this again.)

@Stoppedpuma Stoppedpuma added the bug Something isn't working label Nov 6, 2024
@B-LechCode
Copy link
Collaborator

Which branch did you test this with?

I found something similar and fixed it in dynamicimage branch. I thought it was only there, but maybe I was wrong.

That happens if two consecutive image have the same size and are rgb (without alpha). Is this the case here too? Or was it on initial image load?

@Stoppedpuma
Copy link
Collaborator Author

Stoppedpuma commented Nov 6, 2024

Which branch did you test this with?

Master

This was upon initial load. Not sure if two of the same size in the current directory matter but if so it's possible I did have two of the same size image in the directory.

@B-LechCode
Copy link
Collaborator

B-LechCode commented Nov 8, 2024

Master always uses RGBA images - the bug I discovered isn't "active" in master. Maybe you had just out of memory glitches?
Will test this on my big machine soon.

@Stoppedpuma
Copy link
Collaborator Author

Maybe you had just out of memory glitches?

Definitely a possibility, woelper suggested something similar when I mentioned this. I think since this is unrelated to dynamicimage branch and that the current behaviour will change because of that, it's fine to close this if you can't reproduce? I've tried several times now to get this to happen again and haven't been able to yet. Feel free to close this if you can't reproduce this in your testing.

@woelper
Copy link
Owner

woelper commented Nov 10, 2024

I was able to reproduce corruption if a non-alpha image is opened and then converted to alpha (image has same size). Essentially:

  • Open a jpg with rgb8 mode
  • Open edit panel
  • Select something that has an alpha channel (such as La8)

I previously had corrupted textures, but now this crashes with:

thread 'main' panicked at src/texture_wrapper.rs:165:27:
Problem generating texture: "Texture type Rgba32 with 10960320 bytes, when it should be 21920640 (width: 1960 * height: 2796 * bytes: 4)"

@B-LechCode
Copy link
Collaborator

B-LechCode commented Nov 10, 2024

@woelper it seems you tested with dynamicimage branch. This currently only works with l8, rgb8 and rgba8, other types need to be implemented.

In master there is only rgba8 passed to textue_wrapper, and in master branch is nothing relatable at line 165.

@woelper
Copy link
Owner

woelper commented Nov 10, 2024

I am sorry, yes this is with dynamicimage, correct!

@B-LechCode
Copy link
Collaborator

No problem!

@Stoppedpuma
Copy link
Collaborator Author

Closing in favour of the changes present in #495.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants