Clojurians Log v2
membrane
The size param when creating an image does not do what I expect it to do. With an image that is 1844 × 1218 and I create an ui/image like the following, I get an image that is 1200 × 127. I expect (and want) it to be 1200x792 (or 793, I don’t think it matters how we round here).
(def original-path "test-data/out/to-chatgpt-a-picture-says-more-than-a-thousand-words/image3.png")
(->> (ui/image original-path [1200 nil])
(save! (str original-path "-1200.jpg") :jpg 80))
not totally sure what save! does, but it seems to be working for me locally
(let [original-path "/Users/adrian/Downloads/test-img.png"]
(skia/save-image (str original-path "-1200.jpg")
(ui/image original-path [1200 nil])))assuming it's the save! from x-meta-image, it seems to work for me.
I copied that save! from there 😀 Maybe something is wrong with my repl. I’ll try restarting it.
yea, if it's still not working, I would check the ui/bounds of the original image and the aspect resized image to try and figure out where the problem might be. This could happen if it measured the original image size incorrectly.
Funny thing was that if I measured it myself and calculated the height, that worked. Afk now, so can’t experiment.
Restarting the repl helped! WTF was that about. The repl had been running for a few weeks, but anyway. Well, well, I’m happy. And I guess I just destroyed any reproduction attempt anyway. 😃
weird.
glad it's working again though
there is an image cache.
It's possible that if you loaded the image on disk, loaded the image with membrane, and then changed the image on disk that it might give weird results
there's probably a better API that makes loading more explicit
The image is downloaded as part of the process. So it is “changed” in that sense. Wait… The images change and reuse names as part of the re-download. So image1.png can get to be named image5.png the next run. The cache could screw things up then, I guess. Is there a way I can invalidate the cache?
There is, but that kinda breaks a bunch of the benefits you get from immutability.
There's at least two other options that I think are better:
1.`ui/image` loads the image via protocol. Instead of passing a path which points to a mutable file, I would recommend reading the image contents into a byte-array and passing that to ui/image
Sounds good!
2. If you want to get fancier, you can create a new implementation of the protocol that loads an image based on whatever data makes sense.
actually, there's another 3rd option if you're loading from a url
just use (ui/image (
Oh, well, I have nothing against fancy. But I am very fond of simple + easy. 😃
there's an implementation of the image loading for http://java.net.URL
The files are downloaded in a different part of the system. Then they are on disk. I think reading it into a byte array and pass that to ui/image is my choice here.
here's a snippet that I use for that:
(defn- slurp-bytes
"Slurp the bytes from a slurpable thing"
[x]
(with-open [out (java.io.ByteArrayOutputStream.)]
( ( x) out)
(.toByteArray out))) Haha, you are making my day! Thanks!
Works like a charm! I forced the shuffling of the file names now to test, and it was indeed what screwed up the scaling. With you slurper all is good. Thanks! 🙏