Something very similar was discussed where i had answered which was inevitably method 1. You can see here a similar discussion:
How to add image support to client-server database application?
If you ask why, the fundamental reason why i prefer web method is that when any application demands the actual image, it has following single point of failures.
It becomes a must that finally the database needs to retrieve. The retrieval from DB is more expensive (to other transaction) than retrieval from file system.
Usually there is always some server layer (ASP or C#) which actually makes call to DB (clients, or web browser don't directly call DB). hence, the path has additional point of bottleneck. If there is a static URL (possibly with auth) - the browser can directly fetch rather than going via application server.
Most importantly I guess, when delivering images to many browsers (from a web servers) scaling is much easier that way rather than other way.
Last but most, in many cases, images retrieved using static URLs, can be easily cached by the browser itself to save more resource.
I agree with above answer and the criteria in "To BLOB or Not To BLOB" but most answers focus on speed of retrieval and size of database as a criteria.
My point is that there is additional criteria - is how often images are going to change, and when and how we want deliver these images is equally a critical criteria.
If content of the image is going to keep changing and application logic needs to process them before delivering it makes more sense to deliver via app server (i.e. you can keep in DB). Where as if images by nature itself is quite static - not changing often and needs to be delivered so many times, (set once read/deliver many times) scenario then, it the web is always a preferred method. this applies irrespective of performance of DB.