Burk
Burk

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

|
Embed
Progress spinner
canion
canion

@Burk Is micro.blog changing the colour profile?

|
Embed
Progress spinner
sod
sod

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

|
Embed
Progress spinner
vincent
vincent

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

|
Embed
Progress spinner
odd
odd

@vincent Is it local software or a service?

|
Embed
Progress spinner
vincent
vincent

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

|
Embed
Progress spinner
odd
odd

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

|
Embed
Progress spinner
vincent
vincent

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

|
Embed
Progress spinner
sod
sod

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

|
Embed
Progress spinner
vincent
vincent

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

|
Embed
Progress spinner
vincent
vincent

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

|
Embed
Progress spinner
jsonbecker
jsonbecker

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

|
Embed
Progress spinner
pratik
pratik

@jsonbecker @Burk Not at all optimal if you’re using Micro.blog as a photoblog. @danielpunkass

|
Embed
Progress spinner
manton
manton

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

|
Embed
Progress spinner
jsonbecker
jsonbecker

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

|
Embed
Progress spinner
jsonbecker
jsonbecker

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

|
Embed
Progress spinner
manton
manton

@jsonbecker In theory that shouldn't be necessary anymore. Micro.blog strips orientation out, either before upload or after.

|
Embed
Progress spinner
pratik
pratik

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

|
Embed
Progress spinner
jsonbecker
jsonbecker

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

|
Embed
Progress spinner
jsonbecker
jsonbecker

@pratik in the upload media window, there's an option called Color Mode. Default is "Most Compatible (sRGB)" and you want "Preserve Original".

|
Embed
Progress spinner
pratik
pratik

@jsonbecker Oh dang! Suprised I had never noticed it but haven't used MarsEdit recently to upload photos to my photoblog much

|
Embed
Progress spinner
gaelicWizard
gaelicWizard

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

|
Embed
Progress spinner
gaelicWizard
gaelicWizard

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

|
Embed
Progress spinner
In reply to
manton
manton

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

|
Embed
Progress spinner
Medievalist
Medievalist

@manton Absolutely, strip it all out. People can use data ibn a lot of not good ways. Thank you for thinking about this.

|
Embed
Progress spinner
odd
odd

@vincent 😃👍

|
Embed
Progress spinner
gaelicWizard
gaelicWizard

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

|
Embed
Progress spinner