STBI not loading image despite giving the right directory for absolutely no reason

[MyoskSoftwareCompany]

I tried loading an image but it just doesn't want to load, despite me giving the right path.
main.cpp
GLuint menuBG = render3d->loadTexture("./assets/title.png");
gl2.h
#include <stb_image.h> ... GLuint loadTexture(const char* filename);
stb_image.cpp
#define STB_IMAGE_IMPLEMENTATION #include <stb_image.h>
gl2.cpp
GLuint Renderer::loadTexture(const char* filename) { int w, h, channels; unsigned char* textureData = stbi_load(filename, &w, &h, &channels, 0); if (!textureData) { printf("%s\n", stbi_failure_reason()); return 0; } ...

[yixy-only]

@MyoskSoftwareCompany Could you upload the PNG image you are using here and I'll verify whether the image format is supported by stb_image. It would be nice if you could create a short C++ project that reproduces the problem.

[MyoskSoftwareCompany]

btw the issue just comes whenever i load an image

[nothings]

What does the stbi_failure_reason() printf show?

[yixy-only]

@MyoskSoftwareCompany I downloaded the image you uploaded. After testing, the image is fine and it can be read correctly by stb_image.

• If it is not readable in your project, please change the path to an absolute path instead of a relative path and retest again. Because the current directory may not be what you expected.
• This PNG image is stored in RGB24 format, which means that one pixel takes up 3 bytes. Because you passed 0 to the desired_channels parameter of the stbi_load() function, you get a pixel buffer where a pixel is also stored 3 bytes next to each other. If a pixel takes up 4 bytes in your frame buffer, then you need to copy it pixel by pixel.
• If you want each pixel of the loaded image data to take up 4 bytes instead of 3, pass STBI_rgb_alpha in the desired_channels parameter of the stbi_load() function, which means that each pixel of the load is stored in the RGBA32 format, taking up 4 bytes per pixel, which makes it easier to reading.

[MyoskSoftwareCompany]

the issue still persists

[nothings]

All the evidence we have says that this program (adjusted to compile correctly as needed for your platform) will produce an error:

int main()
{
    FILE *f = fopen("./assets/title.png", "rb");
    puts(f == NULL ? "error" : "success");
    return 0;
}

But if this program produces an error, then the problem is obviously not in stb_image.

[yixy-only]

the issue still persists

@MyoskSoftwareCompany Yes!

STBIDEF stbi_uc *stbi_load(char const *filename, int *x, int *y, int *comp, int req_comp)
{
   FILE *f = stbi__fopen(filename, "rb");
   unsigned char *result;
   if (!f) return stbi__errpuc("can't fopen", "Unable to open file");
   result = stbi_load_from_file(f,x,y,comp,req_comp);
   fclose(f);
   return result;
}

As you can see from the output message and the source code, the reason is that it is not possible to open this file, which may not be able to find the file based on the path. Please check the file path and test using the full path (absolute path) of the file.

You run the program at C:\Users\Admin\Documents\dm. in fact, the current path is at C:\Users\Admin\Documents\dm. If you use relative paths, are you sure the path of the picture is C:\Users\Admin\Documents\dm\assets\title.png?

[MyoskSoftwareCompany]

it's in the dm\build directory

[MyoskSoftwareCompany]

well the absolute path works but it really doesn't change much

[rygorous]

well the absolute path works but it really doesn't change much

On the contrary, when the absolute path works, that means it's a bug on your side.
stb_image doesn't do anything with paths other than pass it through to the standard IO library (which also just passes it through to the OS). If a relative path doesn't work, that means you're passing the wrong path.

Relative paths are relative to the current working directory of the process. It sounds like you seem to think they're relative to the directory the binary is in. That is not how it works on any OS I'm familiar with.

If your processes' current working directory is ...\Documents\dm and your assets are in ...\dm\build\assets, the path you need to pass is build\assets\title.png not assets\title.png. This has nothing to do with stb_image, the same will be true for every other file open call you make.

You can move the assets to just ...\dm\assets which will make the current paths work, you can change the file paths you pass to build\assets\title.png etc., you can run the executable with a different initial current working directory (if you're using Visual Studio, it's in the debugger settings), you can change the current working directory using chdir or direct Windows API calls like SetCurrentDirectory. Do whatever you want. But this has nothing to do with stb_image whatsoever, the reason the stb_image calls with relative paths fail is because you're passing incorrect relative paths.

[MyoskSoftwareCompany]

the working directory isn't in the build directory so i just use cd build and cd ..