Ma questo non è il senso/modo corretto di trattare la questione! Questa qui è soltanto la "visione" che solo tu, da sviluppatore, hai del progetto e dell'ambiente di sviluppo. Non c'entra, non dovrebbe c'entrare nulla con ciò che dovrebbe accadere una volta che la tua applicazione dovesse "vivere" per conto suo fuori da un qualunque ambiente di sviluppo.
Tra l'altro il principio delle risorse (come inteso dai getResource/getResourceAsStream) è da intendersi per la sola lettura, non per la scrittura (non esiste un es. writeResource o roba simile) e inoltre si utilizza tipicamente per quelle risorse (testi, immagini, audio ecc...) che fanno parte fissa della applicazione. Non per cose che sceglie l'utente in modo arbitrario.
Oltretutto le risorse siccome vengono ricercate "in classpath", possono anche stare dentro lo stesso jar dove ci sono le tue classi Java. E a runtime un jar non dovrebbe essere modificato, potrebbe anche non essere possibile modificarlo tecnicamente per vari motivi di locking.
Insomma, non è quello l'approccio giusto.
L'applicazione dovrebbe semplicemente usare una directory "base" sotto cui memorizzare le immagini che l'utente intende caricare e gestire. E questa directory non deve (non dovrebbe) avere nulla a che fare con il tuo workspace, il tuo progetto, la tua "src" ecc...
La scelta di questa directory si può fare in svariati modi:
a) la può scegliere/imporre automaticamente la applicazione, magari basandosi su una qualche directory "notevole" come ad esempio la "home directory" dell'utente che è facilmente rintracciabile da una System property.
b) la può scegliere l'utente in una fase iniziale di setup tramite un apposito "installer" (e chiaramente andrebbe poi configurata da qualche parte in modo che la applicazione la rintracci)
c) la può scegliere sempre l'utente ma ad un primo avvio della applicazione, basandosi sul fatto che all'inizio manca un certo file di configurazione e/o una determinata chiave di configurazione.