No, I did not take the time to dive into the code sample, but another very-common problem in “Windows vs. Linux/Unix” – regardless of programming language – is that Windows uses a case-insensitive file system, but Unix/Linux is case-sensitive.   (Macintoshes offer you the choice, but default to a case-insensitive file system as a nod to their own pre-Unix past.)

So, a request for Perl.jpg, when the underlying file is perl.jpg, will work on a Windows-hosted server, but not on a Linux-hosted one.   Linux will return 404 Not Found simply due to the upper-case “P” vs. the lower-case “p.”   (Similarly, Linux will allow two files to co-exist in the same place, whose names differ only by character-case.   Windows will not.)

The type of operating system being used on the client side does not matter at all.

Web servers ordinarily handle the “forward vs. backward slashes in paths” issue for you transparently, but my experience with modules that are supposed to address filename case-sensitivity – such as Apache’s mod speling (sic ...) is that they simply do not work at all. (And, many are the times when I wished that they did, and have in fact been assured that they do.)

If you observe the page-load (on Linux) using the diagnostic tools of a web browser, you will ordinarily see the “missing” resources returning a 404 Not Found (or some other 4xx code), and you may or may not(!) see a “broken link” icon on your screen.

Another good technique is to copy-and-paste the offending URLs, from the source-code of the page that does not display the image,taking care to copy from the actual HTML data that was transmitted to your browser, not from its source file on the host).   Paste this URL into the address-bar of a new browser tab or window, and observe any messages or error-indications that crop up either on the display or in the browser’s debugger.   (Also notice whether the transmitted URL is somehow different from what you had expected it to be, based on your comparison of the transmitted value to the source.)