User talk:Samsara

Before you delete media as identical, consider whether they have been altered. Usually, they will have "edit", "cropped", "enhanced" or similar in the filename and/or a {{Retouched}} tag. Either one of those should be a big hint to you.

Please do not post standard messages about copyvio if the image I uploaded is a derivative work of another image uploaded to Commons. Such messages should be posted to the original uploader's talk page. I make every effort to ensure that derivative works can be found via links in both directions. Also, please do not post standard messages about deletion if I simply transferred the image from another wiki in good faith because a transfer was requested.

Thank you.

/Archive 00

/Archive 01

White Balancing

In the future, would you mind waiting to do white balancing and such until after the Flickr review bot has confirmed the license on the picture? Thanks, Elisfkc (talk) 18:21, 12 December 2016 (UTC)

I don't understand the logic of this. If I upload with Flickr2Commons, which I assume rejects inappropriately licensed images, then where does the problem with confirming the license arise from? I'm fine waiting, but I find it rather puzzling that this should be necessary. Makes no sense to me. Samsara (talk) 18:33, 12 December 2016 (UTC)

Samsara, as the bot is not human, it will complete the review only if the source and what uploaded here perfectly matches. Otherwise it will tag the file for a human review, which takes much time to complete. And chances that the human reviewer revert the edit and send it back to the bot for review. Usually the bot will process the review within hours; so worth to wait for it. Note that Flickr2Commons and Flickr review bot are different; only the latter is approved for a bot review. Jee 01:26, 13 December 2016 (UTC)

I knew all that. I'm asking why. That's what doesn't make sense. The bot doesn't, in my opinion, work very well. If it's true that Flickr2Commons checks the license before upload, the bot must be updated to not balk at those uploads. Unfortunately, the bot page doesn't even state who runs it. Is that common practice? Samsara (talk) 07:37, 13 December 2016 (UTC)

Now it is User:FlickreviewR 2 by Zhuyifei1999. Jee 08:08, 13 December 2016 (UTC)

Thanks - I believe the above will serve a ping. Samsara (talk) 08:10, 13 December 2016 (UTC)

Sorry but Flickr2Commons is a mostly client-side program, meaning the license checking is done on the user browser (list, check). Any random person with sufficient knowledge in front-end coding can cheat the system and upload any arbitrary image from flickr using the tool, whether the image is free or not, completely bypassing the point of Flickr reviewing. Therefore, FlickreviewR cannot just coded to trust Flick2Commons images blindly. (This is similar to the UploadWizard case, where the functionality is not given to any random user for the very same reason.) --Zhuyifei1999 (talk) 10:28, 13 December 2016 (UTC)

Okay, I can see the problem with code manipulation on the client side. But I can also make the case that once an image is uploaded, I can upload any image over the top and it will not affect the license tag or FlickrReviewer certification. So why it should matter whether a retouched version is uploaded after or before FlickrReviewer visits is still a mystery to anyone who expects things to "just work". More to the point, what is the programming logic that makes it fail in the case alluded to by the OP? Samsara (talk) 10:48, 13 December 2016 (UTC)

Well, I would hope everything should "just work", except "just work" usually difficult. The bot logic on this is quite simple: if the file is different from Flickr's in every single size, refuse to review it automatically, and put the file into manual review queue instead. By different I mean different binary-ly, as in any byte change in the file itself will make the file different --Zhuyifei1999 (talk) 14:10, 13 December 2016 (UTC)

Right, so why can't it use the first version of the file that was uploaded for the comparison? Samsara (talk) 14:21, 13 December 2016 (UTC)

More importantly, if you need to download the file all over again, why don't we have one tool that does both things? I mean, maybe we do? When I looked at the COM:Flickr page, it seemed to be heavily biased in favour of Flickr2Commons... Samsara (talk) 14:24, 13 December 2016 (UTC)

Well, the current algorithm attempts to find the matching on flickr by comparing the image dimensions, then comparing the file size and finally the hash (which reflects the binary data) if necessary. If it have to do this for each one in file upload history, it'll make things more complex.

Btw: I just read the code again. It doesn't even download the file from commons to get the information; instead, it simply get everything from the API. But some of these data simply does not exist for old versions, requiring the bot to download the files itself and making things much slower. (The bot is kind of overloaded already when batch uploader do their work)

As for a unified tool, well, maybe I'm wrong, but I still find a tool and a bot different. A tool has an interface for users to ease the transfer of the files, but the bot does the post-processing of files from all kinds of sources. Perhaps the tool can do some of the work of the bot, but in the currently, it cannot, as explained above (code manipulation), unless it is written in some other ways in the future --Zhuyifei1999 (talk) 16:33, 13 December 2016 (UTC)

Yes - a tool that does more things on the server side. It's just that I've realised over the last 24 hours that "waiting", as the OP suggested, doesn't work particularly well for me. I'd have to completely change my workflow and have a "waiting" folder on the desktop for my edits, and then hope I don't forget to upload those items. So I guess I do mind waiting, but if the result is that I'll be requested to wait, I guess I won't be uploading. It would be nice if people could be flexible and understand that some of us are trying to achieve a certain level of quality in our contributions, and that a poorly white balanced image is not acceptable and needs fixing, not waiting. In the end, I guess what I'm saying is that if I have to sacrifice quality or change my workflow to be slower, then I might prefer to spend my time in other ways. Samsara (talk) 17:02, 13 December 2016 (UTC)

@Zhuyifei1999: Can you just clarify for me - do both Flickr and Commons offer a file hash API? Thanks. Samsara (talk) 17:59, 16 December 2016 (UTC)

Commons: Yes, but fetching hases of old files from api is not directly supported by mwclient (the FlickreviewR's library to interact with Commons) iirc, Flickr: no. --Zhuyifei1999 (talk) 05:20, 17 December 2016 (UTC)

@Zhuyifei1999: Okay, that makes me wonder where the lag comes from - fetching and comparing the hashes should be near-instantaneous. How many Flickr uploads are we trying to process per second? Samsara (talk) 10:02, 17 December 2016 (UTC)

I may have read that too quickly: So we're still downloading images from Flickr all over again and computing our own hashes? That's what I wasn't sure about after your "I just looked at the code again" post. Thanks. Samsara (talk) 10:05, 17 December 2016 (UTC)

No, but to get the hashes for old files are not supported by mwclient last time I checked (perhaps I'm wrong). I might have to get some custom code hacked into it. As for Flickr, perhaps a cache might do. --Zhuyifei1999 (talk) 10:41, 17 December 2016 (UTC)

@Zhuyifei1999: The reason for asking the questions the way I did was that if we're just comparing pre-computed hashes, there's no reason this should take more than a few seconds. I recall that there was a time that bots like SignBot and Anomiebot would respond to edits on en-wp near-instantaneously, so I know it can be done. Making review of licenses by bot fast enough is one way to make this problem go away for the time being. Then one wouldn't need to check old versions or anything like that. Samsara (talk) 11:01, 17 December 2016 (UTC)

Sure, I'll just set the schedule to restart the bot every minute, eh? --Zhuyifei1999 (talk) 11:24, 17 December 2016 (UTC)

I guess that would cut the expected waiting time to 30s, which is almost what I suggested we should aim for. Test it and see? Thanks. Samsara (talk) 11:30, 17 December 2016 (UTC)

Should be working similar to this now --Zhuyifei1999 (talk) 11:50, 17 December 2016 (UTC)

---

@Magnus Manske: Any opinion on whether code could be added to Flickr2Commons to check licence compliance on the server side? Thank you. Samsara (talk) 19:24, 14 December 2016 (UTC)

This is already done by the flinfo tool, which I use to generate the {{Information}} template. --Magnus Manske (talk) 14:54, 15 December 2016 (UTC)

@Magnus Manske: So are there further steps needed to give this official certification and obviate the need for bot review of the license, as per the above discussion? Samsara (talk) 17:58, 15 December 2016 (UTC)

To the best of my knowledge, licenses are already checked. I do not know of anything another bot check would improve. If the review bot does some more special magic, it should be incorporated into the flinfo tool. --Magnus Manske (talk) 20:26, 16 December 2016 (UTC)

Thank you. Zhuyifei1999 (not pinging this time so your ears don't fall off) can you confirm if what Magnus asked about ("special magic") is the case, and can we perhaps get Flickr2Commons uploads the needed accreditation as a result? Samsara (talk) 20:38, 16 December 2016 (UTC)

@Zhuyifei1999: Sorry, I guess I had to ping you after all in relation to the above. ^^ Samsara (talk) 10:10, 17 December 2016 (UTC)

Yeah I sometime miss things in my watchlist. I'm not entirely sure what @Magnus Manske: is talking about, but I would like to point out that list & check are still done on client side of Flickr2Commons.

If Flickr2Commons were to make the check done on server side, please secure the license part of the file description from any possible client side alteration. --Zhuyifei1999 (talk) 10:41, 17 December 2016 (UTC)

@Magnus Manske: Sorry to bother you again, but did you see Zhuyifei's ping above? Thanks. Samsara (talk) 04:52, 4 January 2017 (UTC)

---

Samsara, another option for you is to apply for a license reviewer right. I think it is fine as you're an experience admin in EN and working on media too. A license reviewer can upload directly from the URL and I think it doesn't require a review. I may wrong as I don't remember it correctly. Jee 17:13, 13 December 2016 (UTC)

Thanks, Jee. Upon your suggestion, I looked at that, and it seems that one is not meant to review one's own uploads: Please note that as of 21 February 2012, image-reviewers may not review their own uploads [...] Source: Commons:License review#Instructions for reviewers. It probably changed since you last looked at it. Regards, Samsara (talk) 17:40, 13 December 2016 (UTC)

I know that it not that I'm talking about. upload directly from the URL is a special feature only available to admins and license reviewers. So they don't need to depend Flick2Commons for their uploads. Jee 02:28, 14 December 2016 (UTC)

Thanks for clarifying. I added a request. We'll see what happens. Best regards, Samsara (talk) 10:01, 14 December 2016 (UTC)

Autopatrol given

Hello. I just wanted to let you know that I have granted autopatrol rights to your account; the reason for this is that I believe you are sufficiently trustworthy and experienced to have your contributions automatically marked as "reviewed". This has no effect on your editing, it is simply intended to make it easier for users that are monitoring Recent changes or Recent uploads to find unproductive edits amidst the productive ones like yours. In addition, the Flickr upload feature and an increased number of batch-uploads in UploadWizard, uploading of freely licensed MP3 files, overwriting files uploaded by others and an increased limit for page renames per minute are now available to you. Thank you. Zhuyifei1999 (talk) 14:16, 13 December 2016 (UTC)

Thank you. Samsara (talk) 16:57, 13 December 2016 (UTC)

Your talk page header

It was not my intent to 'misrepresent' your talk page header. Instead, take it as a strong hint that your intended meaning is easily misunderstood. You seem to be saying that you are not responsible for the actual copyright status of files that you transfer to Commons. If so, that is simply wrong. You are responsible for exercising due diligence when transferring files. Revent^talk 12:30, 14 December 2016 (UTC)

What it is trying to say is that I do not wish to be notified when copyvios that I am not responsible for are dealt with. One part of that refers to the case where I have transferred images from another Wiki (probably en-wp) that had been tagged for transfer with appropriate transfer and license tags on them, and no obvious reasons for not being transferred. I am not familiar with any guideline that says that in such cases, a thorough copyvio review must be conducted. So I thank you for pointing out that the wording could be improved, but if you want to suggest that at the time that I made such transfers, there were policies or guidelines in place mandating copyvio review for each image transferred, then I would ask for evidence of such. Then we can look into what tools were available at the time and whether at that time, they would have produced evidence that would have prevented the transfer. Thank you. Samsara (talk) 12:41, 14 December 2016 (UTC)

I should add that I cannot recall, from memory, that there has ever been such a case. I may have added the phrase pre-emptively. So the onus of finding a relevant case, again, would be on you as the one making an allegation, if you wish to do so. Samsara (talk) 12:43, 14 December 2016 (UTC)

I am not making any allegation. I'm simply pointing out that your text seems to imply that you do not feel you are responsible for the copyright status of works that you transfer to Commons, as long as they were flagged for transfer elsewhere. That is not the case... when you upload a file to Commons, you are responsible for ensuring that it complies with our policies before you do so. Revent^talk 13:18, 14 December 2016 (UTC)

Links please. Samsara (talk) 13:22, 14 December 2016 (UTC)

I'm not quite sure what you want links to, unless it's the entirety of Commons policies that refer to copyvios. When you transfer a file to Commons, you are the uploader here, not whatever user flagged the file for transfer somewhere else. The backlog of files flagged for transfer to Commons on enwiki includes massive numbers of files that are not acceptable on Commons... if you started to transfer such problematic files in bulk, you would be stopped from doing so. Revent^talk 13:37, 14 December 2016 (UTC)

(1) Are you familiar with the typical procedure of an en-wp to Commons transwiki upload?

(2) Can or can you not back up your apparent implied claim that a thorough copyvio review must precede each transfer from a WMF wiki? If you cannot, I'm not sure what we're doing here. Samsara (talk) 13:46, 14 December 2016 (UTC)

I'm quite familiar with how transfers work.

I will simply put it this way... if you transferred a significant number of copyvios, with the excuse that someone else flagged them for transfer and you did not bother to check, your argument is highly unlikely to be taken as a legitimate excuse. A transfer is simply an upload of someone else's work... you are going to be held responsible for it's copyright status. I'm simply telling you that as someone with a lot of experience here. Commons is far less concerned with writing massive amounts of documentation of minutiae of accepted practice than enwiki. Revent^talk 14:08, 14 December 2016 (UTC)

I just noticed your comment in your edit summary. Yes, the transfer of copyvios has been a problem on Commons, mainly from non-English wikis (arwiki in particular) that are not at all careful about copyright. Another repeated problem has been when people upload images to enwiki as 'fair use', and then someone else (who does not understand copyright) changes the license and marks them for transfer. Then some third person transfers them, and they are deleted. Then the original uploader comes here and yells at us about their file being deleted, when all 'we' did was delete an upload that was not in accordance with our policies. The only step at which we, on Commons, can stop that process is with the person who uploads the file here... people who upload works that they did not create are responsible for checking their copyright status before they do so. Revent^talk 13:52, 14 December 2016 (UTC)

(talk page stalker) I tried to improve the wordings here. Jee 14:10, 14 December 2016 (UTC)

Removing magenta from photo

Dear Samsara, I've been meaning to thank you for removing the magenta from Joe Rosenthal's photo that I shot in 1990. It looks better than it was because of your skill. Joe's photo is being used a lot lately (the US Marines are spearheading a petition to name a Navy warship after Joe --USSJoe). Do you think you can remove the magenta in Reverend Jim Jones' photo that I took in 1977? Thank you in advance. --Nancy Wong https://commons.wikimedia.org/wiki/File:CommissionerJimJones.JPG

http://usmclife.com/2017/03/marine-vets-urge-lawmakers-name-warship-famous-iwo-jima-photographer/ — Preceding unsigned comment was added by 204.102.74.26 (talk) 21:58, 30 March 2017 (UTC)

File:Edward Weston and Marguerite Mather.jpeg

File:Edward Weston and Marguerite Mather.jpeg has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry. If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues. Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

--Animalparty (talk) 09:28, 11 January 2019 (UTC)