Your ASP application is running locally on the server computer and can access the picture files via the local drive-letter and path "D:...". The "Sharing" functionality you're looking at is used to allow client computers to access the folder via the CIFS / SMB file sharing protocol. It's not necessary to use "Sharing" in the application you're describing.
Your ASP application runs under a security context set by IIS. By default, anonymous users execute ASP applications as the IUSR_machine-name account (an account that is created during IIS installation).
It is necessary that the NTFS access control list (ACL) for the folder / files your ASP application accesses allow the ASP application to access the files. What permission needs to be set in the ACL is determined by the security context the ASP application is running under. If the application is running as an anonymous user (i.e. the remote users aren't performing a Windows authentication) then the IUSR_machine-name user account would need to have permission granted to the folder. Stock NTFS permissions typically allow "Users / Read" and that would be sufficient for the access.
Your screenshot is showing the ACL-- that is, the permissions granted to specific users and groups-- applied to a given folder. This is not an exhaustive list of all the user accounts that the server computer "knows about". That exhaustive list would be accessible in the "Local Users and Groups" tool in the "Computer Management" tool.
Every action performed on a Windows Server machine is performed within a "security context". Every action that an application asks the operating system to perform on behalf of a user must be attributed to a given user or the computer's operating system itself (which, for all intents and purposes, also appears to be a user with the name "SYSTEM" or "LocalSystem" and a special security identifier serial number that identifies it as this particular special user).
When a user accesses your ASP script to view an image IIS executes your script and, in turn, your script asks the operating system to read files. If the user hasn't authenticated to IIS via one of the built-in authentication mechanisms in IIS then the user's access, with respect to the operating system, is assumed to be anonymous and performed using the user account IUSR_machine-name. (Your ASP application may have an authentication component built into it, however that wouldn't influence Windows' conception of "who" the remote user is-- that can only be influenced by a classic ASP application by using the built-in authentication capabilities of IIS.)
It would be far beyond the scope of your question to give you a step-by-step explanation of how the Windows security subsystem evaluates the ACL on a file or folder to determine if a user is granted or denied access. You mention that this isn't familiar to you, so I'd recommend finding a reference that explains how NTFS permissions work. You can experiment on a Windows PC with NTFS permissions and creating local user accounts to get a feel for how it works, as well.