I want to be able to fetch Wikimedia's images, selecting a custom (or lower) resolution than the default's one.
I've found an image that says that it should be possible by changing the URL, however, It doesn't work.
Am I doing it wrong? Is there any other solution using publicly accessible URI?
Some of the ones I tested:
Full res: https://upload.wikimedia.org/wikipedia/commons/4/4c/DNA_Overview2_crop.png
Half res: https://upload.wikimedia.org/wikipedia/commons/4/4c/DNA_Overview2_crop.png/200px-DNA_Overview2_crop.png
Full res: https://upload.wikimedia.org/wikipedia/commons/1/17/Fotothek_df_n-06_0000001.jpg
Half res: https://upload.wikimedia.org/wikipedia/commons/1/17/Fotothek_df_n-06_0000001.jpg/200px-Fotothek_df_n-06_0000001.jpg
Full res: https://upload.wikimedia.org/wikipedia/commons/f/f2/Mount_St._Helens_erupting_blue.jpg
Half res: https://upload.wikimedia.org/wikipedia/commons/f/f2/Mount_St._Helens_erupting_blue.jpg/200px-Mount_St._Helens_erupting_blue.jpg.png
As you can see, none of them work. Is there any other method or a way to do it properly with this one?
This method works if you use "thumb" in the url after "commons/".
So, the low resolution of this:
https://upload.wikimedia.org/wikipedia/commons/f/f2/Mount_St._Helens_erupting_blue.jpg
becomes this:
https://upload.wikimedia.org/wikipedia/commons/thumb/f/f2/Mount_St._Helens_erupting_blue.jpg/200px-Mount_St._Helens_erupting_blue.jpg.png
Related
I'm working on a Gatsby app with Netlify CMS (and hosted on Netlify). Trying to get the metadata working so that Twitter cards display correctly with images.
The metadata is generally all right, but the images aren't showing on the Twitter validator or if I try to post to Twitter. The problem is clearly the images themselves, which are hosted on the site using Gatsby and Gatsby Image Sharp to render.
In fact, the validator seems to show no fundamental issues. Simply, the image doesn't show up:
Example relevant metadata:
<meta name="twitter:url" content="https://example.com/" data-react-helmet="true">
<meta name="twitter:image" content="https://example.com/static/12345/c5b20/blah.jpg" data-react-helmet="true">
<meta data-react-helmet="true" name="twitter:title" content="Site title">
<meta data-react-helmet="true" name="twitter:card" content="summary_large_image">
I know the images the issue, because if I replace my image URL (which is the full image URL) with an external URL, it works fine, showing the full card with image.
Any idea what could be causing this? I'm sizing the image down so it loads quickly, and it seems to load just fine directly (eg). (I mean, is there something weird/off about that image?)
NOTE: In a previous version of this question, I referenced Cloudinary and Uploadcare, but have since removed those two in a branch to simplify the problem. (They seem to have been unecessary holdovers from the starter app I used.) You can now see an example page for that branch here and the associated image in the twitter:image tag here. I feed this pre-processed/shrunk image into the header using React Helmet (and Gatsby React Helmet) and using the following code in my GraphQL call to get the image associated with the blogpost in that particular, smaller format:
featuredimage {
childImageSharp {
fixed(width: 480, quality: 75) {
src
}
}
Second Note/thought: Should I be worried about the fact that the pages in production seem to be re-rendering on every reload? Isn't SSR supposed to ensure that doesn't happen? I tested this by including a call to Math.random(), hidden, in the page. You can see the result by running document.getElementsByClassName('document')[0].children[0].innerText, and note that it produces a different number on each page reload. This implies to me that the whole page is being re-rendered by the client. Isn't that wrong? Why would that be happening? Might that relate to some sort of client processing of the images on each request, which might be screwing up the Twitter cards?
Third update: I put together a simpler reproduction here. It's based off of this starter template, with Uploadcare/Cloudinary removed and Twitter card metadata added to the header. Other than that, and removing unnecessary pages, I didn't make any other changes. I used this starter for a repro rather than a vanilla starter app, because I'm unsure whether the issue is caused by the interaction of Netlify CMS and the Gatsby Sharp Image plugin. I might try to put together a second reproduction. For now, the code for this repo is here, and the pages that should show Twitter cards are the blog posts, such as this one.
ACTUALLY, it seems that a super basic reproduction, with Gatsby 3 and no Netlify CMS or anything, has the same issue. Here's the minimal reproduction, with the image taken from src/images using an allImageSharp query and inserted into the metadata for each page. Code here.
FINAL UPDATE
Based on Derek's answer below, I removed the #reach/router stuff, and got the site URL from Netlify build env variables. It appeared that #reach/router only gave this information when JS was running, which excluded the Twitterbot, resulting in an undefined base URL, which broke the Twitter image. Including the URL from Netlify (using process.env.URL in the Gatsby config and pulling that in through a siteMetadata query) fixed the problem!
Update:
I think I might have found the issue. When opening the minimal production with script disabled, the url for twitter:image is invalid:
<meta data-react-helmet="true" name="twitter:image" content="undefined/static/03475800ca60d2a62669c6ad87f5fda0/58026/energy.jpg">
So for some reasons, during build, the hostname is missing, but when JS kicks in, it appears (Might have something to do with the way you get the hostname). Twitter crawlers probably does not have JS enabled & couldn't fetch the image.
Make sure your opengraph images are absolute urls with https:// or http:// protocols. I checked your example link & saw that it was a relative link (/static/etc.)
For Twitter, it seems to demand social cards to be 2:1
Images for this Card support an aspect ratio of 2:1 with minimum dimensions of 300x157 or maximum of 4096x4096 pixels.
https://developer.twitter.com/en/docs/twitter-for-websites/cards/overview/summary-card-with-large-image
If you're using the latest Gatsby image plugin, you can use aspectRatio to crop the image.
Also note that you can skip the twitter:image tag, if your og:image has already satisfied Twitter's card requirement.
SSR does not mean to never run JS in the client, React will render your page on the client side regardless of SSR.
This was solved here: https://github.com/gatsbyjs/gatsby/discussions/32100.
"location and thus origin is not available during gatsby build and thus the generated HTML has undefined there."
I got it working by changing the way I create the image URL inside seo.js from this:
let origin = "";
if (typeof window !== "undefined") {
origin = window.location.origin;
}
const image = origin + imageSrc;
to this:
const imageSrc = thumbnail && thumbnail.childImageSharp.fixed.src;
const image = site.siteMetadata?.siteUrl + imageSrc;
You need to use siteUrl from siteMetadata.
Below is my pageQuery from inside blog-post.js:
export const pageQuery = graphql`
query BlogPostBySlug(
$id: String!
$previousPostId: String
$nextPostId: String
) {
site {
siteMetadata {
title
siteUrl
}
}
markdownRemark(id: { eq: $id }) {
id
excerpt(pruneLength: 160)
html
frontmatter {
title
date(formatString: "MMMM DD, YYYY")
description
thumbnail {
childImageSharp {
fixed(width: 1200) {
...GatsbyImageSharpFixed
}
}
}
}
}
}
`
Is it possible to upload an image with my own size to vimeo?
For instance, I want my thumbnail_medium to be 400x400, but every time I am uploading the 400x400 I am getting the 200x150 after retrieving the video data by the url https://vimeo.com/api/v2/video/myVideoIdGoesHere.json.
Thank you.
Try replacing '200x150.webp' at the end of thumbnail_medium with '400x400'
That postfix is what determines the size. I'd recommend indexing on '_' and appending the dimensions you desire (the '.webp' is unnecessary). Something like this...
const newURL = oldURL.substring(0, oldURL.indexOf('_')) + '_400x400'
If you look at thumbnail_small, the only difference in the url is a change of the postfix
I am trying to extract image frames from a video. I am passing the video URL as a command line argument. I am using a long URL as below.
Extract.exe C:\Users\Public\Videos\Sample Videos\Wildlife.wmv
This doesn't work and it calls the help(), maybe because of argument count not being equal to 2. (The argument count shows 3).
When I put a short URL as below,
Extract.exe F:\Wildlife.wmv
It works fine.
What could be the problem with the long URL command line ? How can I overcome this hurdle ?
You have some guidance for me ? Well, I am glad to have it with many thanks !!!
Its because you have spaces in your path name
Extract.exe "C:\Users\Public\Videos\Sample Videos\Wildlife.wmv"
should work.
I'm trying to add global hotkey support to Spotify (and others). For this I have to execute a content script in the player app iframe, but no matter what pattern I try Firefox just won't execute my content script.
This is what I try to do:
var data = require("sdk/self").data;
var pageMod = require("sdk/page-mod");
pageMod.PageMod({
include: /^https?:\/\/play\.spotify\.com\/apps\/player\/.+/,
attachTo: ["frame"],
contentScriptFile: [data.url("content.js")]
});
Has anyone any idea what could be wrong? How can I make it match?
See:
https://bitbucket.org/panzi/play-control/src/f1dbd217661c0f09d3615dce7b8b1cab9f8fbf70/browser-plugin/firefox/playcontrol-spotify/lib/main.js?at=default
The same thing for Chrome works perfectly well:
https://bitbucket.org/panzi/play-control/src/f1dbd217661c0f09d3615dce7b8b1cab9f8fbf70/browser-plugin/chrome/playcontrol-spotify/?at=default
I'm a regex noob, but in the doc examples, they don't use ^ even when the string starts with 'http'.
Try getting progressively more stringent to see which part of the regex it doesn't like. Throw an onAttach: console.log("pageMod attached"), in there to make sure it isn't being attached and something else isn't causing the problem.
/.*play\.spotify\.com\/apps\/player.*/ If this works, then either it doesn't like the beginning or the end. Try:
/https?:\/\/play\.spotify\.com\/apps\/player.*/
/^https?:\/\/play\.spotify\.com\/apps\/player.*/
.*play\.spotify\.com\/apps\/player\/.*/
.*play\.spotify\.com\/apps\/player\/.+/
If all of the above work, then your string should work too.
URL matching works the way I've written it. The bug was something else.
I have written a program that relies on Magick++ simply for importing and exporting of a wide variety of image formats. It uses Image.getPixels() to get a PixelPacket, does a lot of matrix transformations, then calls Image.syncPixels() before writing a new image. The general approach is the same as the example shown in Magick++'s documentation. More or less, the relevant code is:
Magick::Image image("image01.bmp");
image.modifyImage();
Magick::PixelPacket *imagePixels = image.getPixels(0, 0, 10, 10);
// Matrix manipulation occurs here.
// All actual changes to the PixelPacket direct changes to pixels like so:
imagePixels[i].red = 4; // or any other integer
// finally, after matrix manipulation is done
image.syncPixels();
image.write("image01_transformed.bmp");
When I run the above code, the new image file ("image01_transformed.bmp" in this example) ends up being the same as the original. However, if I write it to a different format, such as "image01_transformed.ppm", I get the correct result: a modified image. I assume this is due to a cached version of the format-encoded image, and that Magick++ is for some reason not aware that the image is actually changed and therefore the cache is out of date. I tested this idea by adding image.blur(1.0, 0.1); immediately before image.syncPixels();, and forcing this inconsequential change did indeed result in the correct result for same-format images.
Is there a way to force Magick++ to realize that the cache is out-of-date? Am I using getPixels() and syncPixels() incorrectly in the first place? Thanks!