Allow media images to be shown instead of squished down to 110 px.

[lightnin]

At least with my archives, the images are limited to 110px tall - kind of weird. This allows them to take up the column width.

There are still issues with the code failing to recognize when the media type is video, and giving it an img tag. That's beyond my paygrade sadly.

[lightnin]

It looks like this could be used to at least give the video the proper video tag, instead of tagging it as an image which is what happens now, causing the video to fail to load.

import magic
mime = magic.Magic(mime=True)
filename = mime.from_file(path_to_video)
if filename.find('video') != -1:
   print('it is video') 

From: https://stackoverflow.com/questions/14919609/how-to-check-if-a-file-is-a-video

[kensanata]

Yeah, I’m happy to take merge requests.

[kensanata]

I'm a bit unsure of what you're aiming for with this particular change. On my instance, things look a bit like this:

Do you have a screenshot to share?

[kensanata]

I guess I'd just click on images for the full size, which is what I have to do on my instance, too (but without a fancy lightbox).

That's why a result like this for my HTML archive seems great, to me:

And when I click on it, I get full size… no problem.

[lightnin]

Ah - I can see that having a very small preview section of the image at actual size might make sense when the image is a photograph of text. However, when the image is more like the images you shared of the Limat, if only a small portion of the image is made visible, it is difficult to recognize what the whole is. For this reason I think it is much better if the HTML page generator shows the most or if not all of the image within the space of the frame or div set for it- which seems to be what your Limmat test case is doing. Here is how things look on my html generated pages: The images are unrecognizable, because they show only a small section.

For consistency, when generating HTML pages I think it is best to follow the general design practices of Mastodon toots, which is to show all or most of the image. This is most likely what most users will expect.

[kensanata]

I agree with the idea that we should follow the design practices of Mastodon in the output. Unfortunately, we're still not there. Getting rid of the height limit is definitely not how Mastodon does it. Take a look at the following example. The patch only works well for landscape images, I think.

I still think you have some sort of setting that I don't have because you're so confident in your assessment and yet it looks so very much unlike the Mastodon I know. Checking the instances where I have accounts, I see now that two of the instances I'm on use v4.1.0+glitch, so perhaps Glitch is giving me a different look. I also have this option checked: "Crop images in non-expanded posts to 16x9". I bet it's this option that changes the look for me.

I merged the change because I agree it looks better than before, but I'm still not happy. Sadly, I'm also not in a position to figure out what it is that we really need.

I prefer cropped images:

If the number of images is less than 4, I want dynamic sizing:

I'm sure this can be achieved by some clever use of CSS if we make a change to html.py so that the CSS knows how many images there are. Sadly, the following doesn't quite work and I still don't know how to center the cropped images. 1 2 … more investigation is required and I don't have the time to do it. Do you know how to achieve the desired effect?

In write_status:

        class_attribute = 'more';
        n = len(attachments);
        if n == 1:
            class_attribute = 'one'
        elif n == 2:
            class_attribute = 'two'
        elif n == 3:
            class_attribute = 'three'
        elif n == 4:
            class_attribute = 'four'
        media = media_template % (class_attribute, ''.join(previews))

And in the CSS section:

.media {
        margin-top: 8px;
        margin-bottom: 8px;
        height: 320px;
        overflow: hidden;
}
.media a {
        display: block;
        float: left;
        position: relative;
        border: 1px solid #282c37;
        box-sizing: border-box;
        overflow: hidden;
}
.one a {
        max-width: 100%%;
        max-height: 100%%;
        display: block;
}
.two a {
        max-width: 50%%;
        max-height: 100%%;
        display: block;
}
.three a:first-child {
        max-width: 50%%;
        max-height: 100%%;
        display: block;
}
.three a {
        max-width: 50%%;
        max-height: 50%%;
        display: block;
}
.more a, .four a {
        max-width: 50%%;
        max-height: 50%%;
        display: block;
}

[lapineige]

Getting rid of the height limit is definitely not how Mastodon does it.

It does, if you deactivate the 16/9 cropping.

[kensanata]

Ah, so that explains why I was so confused. And what is your preference? 😄

[lightnin]

Just to say - I think what you describe is definitely what's needed. I agree that handling the different number of images in a way that is similar to what Mastodon naturally does on the timeline should be the goal.

But my ability to blunder through CSS is not strong, and there's only a few more weeks until the PhD is turned in... I'm afraid I can't finish what I've started here. I may try to take a look again in August. Apologies for that - and thanks for making and sharing this software!

[lapineige]

Ah, so that explains why I was so confused. And what is your preference? 😄

If you ask me, I would say un-cropped as long as there is only one image, for several images and a grid of a fixed format (maximal size) as Mastodon does.

Screen space is not much of an issue in such an archive in my opinion. And it ease the reading of some media.

That said, it's only my opinion, and I only use that view for searching thought conversations content. I suppose others have different use of this HTML view.