If I post a photo to multiple places, the one on micro.blog is always different visually.. muted colors.
@Burk @canion Yeah, @manton is up to something when re-encoding images. đ Artifacts, like banding (vertical lines) are common as well.
@vincent I guess with a service the cost climb quickly. Personally I havenât minded the quality of my uploads, but Iâm not very concerned with that here. As long as I have the original, itâs ok, but I can see how some are concerned about it.
@vincent Maybe the resizer could have some kind of sanity check? If the photo has a reasonable file size already, only strip metadata. An interesting thing now is that my photos on the Micro.blog timeline sometimes gets heavier than the original. đ
Take my latest photo post as an example. The original is 175 kB vs. the Micro.blog optimized one weighing in at 244 kB (and looking worse).
@Burk how are you posting to Micro.blog? MarsEdit by default strips color space info that really fucks up photos. But you can change that setting. Some ways of adding photos through other means also causes them to get processed and compressed and that csn strip some of that info too, really reducing dynamic range.
@Burk @sod @vincent I think part of the problem is that there are so many places for the photo to be resized⊠Before upload in the client, on the server when receiving the data, and then finally in the timeline when displaying it. I wouldnât be surprised if a photo is sometimes recompressed 3 times. I think if we could optimize that to mostly 1 time, might go a long way to improving this.
@pratik to be fair to @danielpunkass, itâs very easy to say Preserve Color Space or whateer itâs called and to make that the defaultâ I do! When the feature first was added, I suspect browser support for higher dynamic range color spaces was quite limited.
@manton a related problem I used to run into more, but not so much lately, was that I had to run mogrify on some photos to get the orientation right.
@jsonbecker In theory that shouldnât be necessary anymore. Micro.blog strips orientation out, either before upload or after.
@manton yeah itâs been better lately, but I think my issue was actually older digital photos that I âfixedâ in Apple Photos, which relied on orientation meta data. So I had to mogrify the photos to make them âactuallyâ oriented correctly and not just reliant on the metatdata for that.
@pratik in the upload media window, thereâs an option called Color Mode. Default is âMost Compatible (sRGB)â and you want âPreserve Originalâ.
@jsonbecker Oh dang! Suprised I had never noticed it but havenât used MarsEdit recently to upload photos to my photoblog much
@manton it makes sense to resize for the timeline for bandwidth savings, but otherwise it should never be damaged without express user intent. The app should never modify the image unless the user chooses to do so specifically, neither should the backend.
@manton stripping location metadata makes sense because itâs too easy for people to inadvertently include, but other metadata shouldnât be summarily stripped⊠what I post should be what I post, not some near approximationâŠ
@gaelicWizard The problem is that most people donât know what data is included. Other non-location data could be considered private too, such as camera type. I think itâs safest to strip all of it out, because the original is always going to be safe on the personâs phone or computer.
@manton Absolutely, strip it all out. People can use data ibn a lot of not good ways. Thank you for thinking about this.
@manton I find that assumption unsupportable. Maybe technical people who have first-hand experience with data loss may be careful about backups, and even then itâs a poor assumption.
Alsö, I canât imagine camera model being sensitive but thereâs no reason not to strip the two or five fields that you are suspicious of, not the whole EXIF block.