# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 43
# self = https://watcher.sour.is/conv/g3th6hq
@lyse Wait, isn’t -strip supposed to only strip metadata? How can this account for such a difference in size? 😱 Also, nice to see that the little guys are doing fine. 🐸
@lyse Wait, isn’t -strip supposed to only strip metadata? How can this account for such a difference in size? 😱 Also, nice to see that the little guys are doing fine. 🐸
@lyse Wait, isn’t -strip supposed to only strip metadata? How can this account for such a difference in size? 😱 Also, nice to see that the little guys are doing fine. 🐸
@movq Yes, all the EXIF really bloats them. ~50 vs. 100 KiB is a lot. When I visted them on Monday, I could only see about 20 individuals. Twenty. Luckily they just stayed at lower depths. Just checked on them and they're in big clusters again.~
@lyse Wow. I would never have expected this. The size of the thumbnails of my /pics went down from 6.3 MB to 2.3 MB. How can metadata be *that* big! I’m using -strip in https://uninformativ.de/git/html-index now, thanks for the tip! 🤯
@lyse Wow. I would never have expected this. The size of the thumbnails of my /pics went down from 6.3 MB to 2.3 MB. How can metadata be *that* big! I’m using -strip in https://uninformativ.de/git/html-index now, thanks for the tip! 🤯
@lyse Wow. I would never have expected this. The size of the thumbnails of my /pics went down from 6.3 MB to 2.3 MB. How can metadata be *that* big! I’m using -strip in https://uninformativ.de/git/html-index now, thanks for the tip! 🤯
@movq Yeah, that's totally crazy. I couldn't believe it either! O_o Now I'm wondering whether I should simply strip all the meta data from the bigger photos, too. Is anyone really interested in those? I will definitely also use your -quality 50. This seems like a really good idea. Thanks for sharing! Now I'm even down to ~20 KiB per preview image, the quality difference is very hard to spot with the naked eye.~
@movq WTF, why's there XML in your thumbnails in the first place!? How did that happen?
@movq I actually never wanted to see stuff like that. But alright, let's keep it for now. XMP, so many things I've never heard of. ;-) XML is so much bloat for so little actual information. It amazes me every time.
@movq @lyse Perhaps you guys can make some suggestions for the Yarn/twtd backend and it’s image processing ? My being vision impaired makes it hard for me, so maybe my code could be more optimal ?
@movq @lyse Perhaps you guys can make some suggestions for the Yarn/twtd backend and it’s image processing ? My being vision impaired makes it hard for me, so maybe my code could be more optimal ?
@prologic I’ll take a look, but so far, I haven’t noticed anything weird. 😊
@prologic I’ll take a look, but so far, I haven’t noticed anything weird. 😊
@prologic I’ll take a look, but so far, I haven’t noticed anything weird. 😊
@movq @prologic Me neither. :-) But I'll have a closer look at the source some day this week. Be warned, don't expect too much, images are really not my domain of expertise.
@prologic Okay, I had a look at the image code and noticed, that we don't support JPEG. When requesting an image using Accept: image/jpeg, a PNG is delivered instead. Locally converting the PNG to JPEG using convert, results in a much smaller size. I used @off_grid_living's solar panels https://twtxt.net/media/xpdN2Zg3WrZCLAhBo4Wu2U and got the following file sizes: 312.5 KiB PNG, 214.5 KiB WebP and 76.8 KiB JPEG. For photos, JPEG's savings are quite significant. EXIF information are stripped when uploading an image, which is fine to me, @movq would disagree on that. ;-) Maybe the hardcoded maximum image resize width of 720 px would be something to make configurable by twtd operators.
@lyse Thanks for your PR btw! It has been merged! 👌
Regarding image/jpeg support. Originally I designed the image processing to only really support WebP and PNG, WebP if possible and a fallback to PNG. In hindsight maybe JPEG should be supported oto? It wouldn't take a lot of extra processing to handle this.
In an ideal world, I'd refactor the code entirely into a separate service that accepts an image upload, returns a unique URI for the resource and does the processing in the background. So that the user experience is quicker and more fluid...
@lyse Thanks for your PR btw! It has been merged! 👌\n\nRegarding image/jpeg support. Originally I designed the image processing to only really support WebP and PNG, WebP if possible and a fallback to PNG. In hindsight maybe JPEG should be supported oto? It wouldn't take a lot of extra processing to handle this.\n\nIn an ideal world, I'd refactor the code entirely into a separate service that accepts an image upload, returns a unique URI for the resource and does the processing in the background. So that the user experience is quicker and more fluid...
@lyse Thanks for your PR btw! It has been merged! 👌
Regarding image/jpeg support. Originally I designed the image processing to only really support WebP and PNG, WebP if possible and a fallback to PNG. In hindsight maybe JPEG should be supported oto? It wouldn't take a lot of extra processing to handle this.
In an ideal world, I'd refactor the code entirely into a separate service that accepts an image upload, returns a unique URI for the resource and does the processing in the background. So that the user experience is quicker and more fluid...
But also so I can decouple pods and twtd from having C-level dependencies and break out any "media handling / serving" to a separate thing that can scale indepently.
But also so I can decouple pods and twtd from having C-level dependencies and break out any "media handling / serving" to a separate thing that can scale indepently.
@prologic No worries. I need to think about splitting the programs a bit more. Currently I'm trying to test your latest change regarding the configurable fetch interval. At the moment it looks like it's not having any observable effect, but I'm probably doing something wrong. Back to testing.
@lyse @movq @prologic Interesting comments Lyse. The image you speak of is 37.9KB, and I use James camera which makes a 6MB file. I than get the image in Windows 8 Photos viewer, and press Screen Shot, Paste the file into MSPaint, a primitive Paint program. I than use capture size to get the image again, and paint it again into Paint, unchanged. It is saved as a JPEG file, reducing the image from 6MB to 37.9 KB. The file is than used for Internet publishing on my website, spiritualsprings.org . It would be nice if software made image files smaller automaticly
@lyse @movq @prologic Interesting comments Lyse. The image you speak of is 37.9KB, and I use James camera which makes a 6MB file. I than get the image in Windows 8 Photos viewer, and press Screen Shot, Paste the file into MSPaint, a primitive Paint program. I than use capture size to get the image again, and paint it again into Paint, unchanged. It is saved as a JPEG file, reducing the image from 6MB to 37.9 KB. The file is than used for Internet publishing on my website, spiritualsprings.org . It would be nice if software made image files smaller automaticly
@lyse I think based on your feedback it was me that did something wrong 🤣\n\nl redo it to actually change the job schedule 👌
@lyse I think based on your feedback it was me that did something wrong 🤣
l redo it to actually change the job schedule 👌
@lyse I think based on your feedback it was me that did something wrong 🤣
l redo it to actually change the job schedule 👌
@off_grid_living That's an interesting observation, that the source image is even smaller! Your workflow seems overly complicated to me. Isn't there a resize option in this image viewer? Maybe get yourself a proper image viewer. When I was on Windows decades ago I used Irfanview, not sure whether this still exists. As for dedicated image editing in a GUI, I can recommend GIMP. I reckon ImageMagick is availabe on Windows as well, you could easily automate resizing with it in a script if you have the courage to use the command line: convert -resize 400x300 -strip -quality 50 ORIGINAL.JPG RESIZED.JPG is what I use.
@lyse I see Lyse, maybe I am old fashioned and use what I know, ie PAINT. It's a primitive program but useful for many things. I did once use a resize program to convert dozens of files to small images. Thanks for the help though.
@lyse I see Lyse, maybe I am old fashioned and use what I know, ie PAINT. It's a primitive program but useful for many things. I did once use a resize program to convert dozens of files to small images. Thanks for the help though.