Seriously, if you think no work was done in it, why not switch all usages over to the unrestricted version, https://www.loc.gov/pictures/resource/pga.04038/ ? The one with rips, pockmarks, poor colour fidelity, etc.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 11 2022
That actually works out well for Battle of Spottsylvania by Thure de Thulstrup.jpg where the text outside the hcard template is not related to authorship
Apr 25 2022
Jan 16 2022
Little followup. Here we see Media Viewer turning a CC-by image that requires crediting me into a Public Domain image that does not credit me.
I should probably give an example, to show the problem is widespread.
In T68606#7624566, @Aklapper wrote:@AdamCuerden: Please read and follow https://www.mediawiki.org/wiki/Bug_management/Phabricator_etiquette If you would like to be active here. This is an issue tracker and not a random forum. Thanks for your understanding.
I've just discovered this is more broken than I thought: It's not even an edge case: It can't handle more than one {{Creator}} template. So in literally any case where an image has more than one creator, it will fail to credit at least one person.
Look, it's been 8 years. Make a fix, and if it causes problems, make another, but in those 8 years countless sites have used my work, not needed the big version, so just used the Media Viewer copy. And I want my work used, but I really would like credit, and, honestly, have a legal right to it. The legal concept of moral rights kind of have to overwhelm "it might not look nice in some cases", because I'm honestly infinitely patient for Wikipedia's bullcrap to sort itself out, but not everyone's going to be, and this affects literally every situation where a more-famous author with a Creator template has a co-author that doesn't.
Jan 14 2022
Seriously, how will structured data be any more structured than "The stuff in the Author field of the Information Template. Include it all or be violating copyright? Or are you going to hand-redo a few thousand files to suit this new data?
Mar 21 2019
That's unfair. FileImporter IS a good substitute in most cases. But if it has a limit, there are going to be cases it needs done by hand.
FileImporter may eventually be a good substitute, but unless the maximum size on it is moved WAY, WAY up, we need a way to do it by hand.
In T218745#5041204, @Umherirrender wrote:Maybe the new beta FileImporter can handle your file? That would also copy the history and that sounds better than the url upload
Mar 19 2019
Also: There are copyrighted images on many of the whitelisted sites - loc.gov bnf.fr , most likely others. It's not like the whitelist means the site is 100% copyright-free.
No more so than any other problematic upload on Commons. They happen sometimes; they're probably less likely to happen using the method that requires a fair bit more technical knowledge.
Checking, it's wikimedia.org since the actual site is uploads.wikimedia.org
Jun 6 2017
May 6 2017
The biggest problem with this patch is that it came out of a request to
allow rotations in multiples of 90°. Commons does not need or want anything
besides that, because you don't want eyeballed rotations, and 90° multiples
are about the only ones you can do eyeballing that are worth doing.
Anything else you want people taking the image to proper image editing
software, with guidelines and care.
Oct 27 2016
I don't see it working at that link? Is it turned back off?
Sep 16 2016
More practically, I think the only real issue is with very tall, but narrow images that have captions. Could a minimum width/height be instituted, so that the space occupied can't get too narrow leading to
Aug 15 2016
Any updates on progress?
Jul 26 2016
Jun 28 2016
As I understand it, all JPEGs are sharpened the same amount, and all PNGs not at all. My experience with older photos (with film grain and such) and engravings is that some sharpening is needed, though I suspect a bit less could work in most cases. But we need this feature.
Jun 27 2016
Anyway, as I said (with a typo correction): I don't think any major translator service doesn't start with a machine translation and then improve it by comparison with the original language's text. This machine translation is already available, and offered to other languages, help those of us out who translate into English: Turn it on; if people don't want it, they don't have to use it.
...Oops. Serves me right for trying to do this on a dodgy wifi. Sorry for the triple-merge
Jun 26 2016
Feb 5 2016
Well, we agree it's bad to leave out one of the credits, right?
Feb 3 2016
Remember that images degrade with every rotation. Further, we're rotating rectangles, not circles: if you rotate a rectangle anything but 90 degrees, you end up with either triangular gaps in the corners where the rotated image is put into a larger box, or you have to crop, throwing information away. **We do not want to encourage throwing away information before it's even saved, using a Web-based device that people will quickly eyeball the rotation and hit save on, because what else are they going to do.
Again, please only allow 90 degree rotations. We do NOT, under ANY circumstances want people guessing at rotations at upload, then doing rough crops before any original copy has even been saved. 90 degree rotations are safe both at upload or later. Anything more than that, and we must save the original copy first
Jan 12 2016
Last three images now, sorry: Wanted to fix some bright spots.
Sep 24 2015
Thank you so much for this.
this has surely gone on long enough, with maqsses of lost resources.
Sep 16 2015
In T35186#1642142, @Gilles wrote:As stated earlier in the comment thread, 90 degree rotations can be performed losslessly on many formats (the vast majority of our originals, when you look at the distribution of file types), including JPEG without having to use EXIF rotation. jpegtran is what allows lossless EXIF-free rotation of JPEGs.
Sep 15 2015
See http://www.daveperrett.com/articles/2012/07/28/exif-orientation-handling-is-a-ghetto/ - it's not perfectly supported by every website, but Wikipedia handles it quite well, and it's not like we haven't led things before. OGG support was almost non-existent before Wikipedia.
It rather seems like the scope of this is growing into something the community doesn't want or need, when all we really need is the ability to correct simple 90° rotations. Hell, even just the ability to set an orientation code in the EXIF might be enough.
That's what's image editing programs are for. I think it's actually kind of dangerous: Each change degrades an image slightly, and arbitrary rotation - in the absence of things like guides and such - are likely to be too approximate. And heaven help us if we allow arbitrary cropping on upload - we already have a problem with engravings and such being inappropriately cropped in ways that kills a lot of their reusability. (e.g. removing the edges, meaning they can no longer be reproduced in their original form; removing text that was a part of the engraving (and often not documenting it) etc.
Sep 14 2015
Can I make a request that this ONLY be done for 90, 180, or 270° rotations? Anything that needs a crop or transparency should require actual human thought.
Aug 6 2015
Agreed. Processes affected include, [[:en:Wikipedia:Featured picture candidates]] and - it would appear - a good section of [[:en:WP:TWINKLE]]. These are perfectly fixable, but '''there is literally no reason whatsoever on the developer's part to break them without any warning whatsoever.
Jul 26 2015
Jul 24 2015
Last two links should be