If I post a photo to multiple places, the one on micro.blog is always different visually.. muted colors.

@Burk Is micro.blog changing the colour profile?

@Burk @canion Yeah, @manton is up to something when re-encoding images. 😅 Artifacts, like banding (vertical lines) are common as well.

@sod @canion @Burk - yes, it's the image resizer. I've brought this up early last year... but it's still an issue. Needs looking at, because images are important.

@vincent Is it local software or a service?

@odd Local. It uses ImageMagick, with the rmagick gem. Images used to be much worse, and I know Manton changed a few things last year after my feedback.

@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.

@odd it only affects the timelines on Micro.blog, because we want to serve smaller images. The originals are not touched by the resizer for hosted sites.

@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).

@sod Oh dear. Yeah, the difference is quite noticable... Best to send in help@micro.blog with your findings. Easier for Manton to pick out/up.

@sod @odd @Burk - I've added an internal note regarding image resizing, so we don't forget.

@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.

@jsonbecker Can you point me to where I can fix that?

@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.

@vincent 😃👍

@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.