@Danmichaelo, is lossless mode still working. I used to get messages that the crop size had been adjusted because I wasn't starting on a multiple of 8 or 16, but this has gone away. Similarly, there's a bug report on github (#170) reporting that files that should be uncroppable in lossless mode are now working, but produce the same files as if they were in precise mode. Is the tool silently falling back to precise when lossless doesn't work (which would be undesirable), or is something else going on here? Perhaps a bug introduced in the September 2020 refactoring? Ahecht (TALK PAGE) 14:59, 15 June 2022 (UTC)[reply]
Looking into the code more, it seems like the September 2020 refactor fundamentally broke things. The various types of crop were broken out into subclasses (for example, lossless Jpeg cropping was broken out into JpegFile and Gif cropping to GifFile), but as far as I can tell the only subclasses that are actually being called out by the program in FileRepository.php are TiffFile, DjvuFile, PdfFile, and SvgFile, all of which return errors instead of actually working. All other file types are being handled by the generic imagemagick call in File.php.
This is why lossless crops are no longer lossless, Gif files say they are being cropped with precise or lossless mode instead of "gif mode", and TIFFs, PDFs, and DJVUs no longer work.
Since about 9-2021 Danmichaelo's only contributions have been edits to wikidata and some edits in norwegian and finnish wikipedia about some meta-topics (bot problems, ...). I seem to remember that them was unhappy with a decission at english wikipedia. That leaves two ways of action: Appease them to return to wikipedia, or find a new maintainer for croptool. Just waiting woll not help. C.Suthorn (talk) 15:34, 15 January 2023 (UTC)[reply]
i know someone might have to take over, but i reposted this thread because this is a major issue which should not be archived until it's resolved. RZuo (talk) 18:25, 15 January 2023 (UTC)[reply]
i think, with https://github.com/danmichaelo/croptool/pull/182 merged 2 days ago, lossless mode has now returned. i just tried previewing random crops in lossless mode and they were now being augmented to the left and the top again.
If this is done, there needs to be some control over it: for example, we don't necessarily want to copy "depicts" for things that are outside of the resulting crop. - Jmabel ! talk20:52, 29 May 2023 (UTC)[reply]
Feature request re updating of Template:Image extracted[edit]
Currently this tool will usefully add or update {{Image extracted}} on existing file pages when a crop is generated. However, this is unnecessary when the new crop overrides an existing one, and which is already listed in the template at the source file page. A useful feature request is to suppress the updating of {{Image extracted}} when the cropped image is already listed there. — RAVENPVFF·talk·16:57, 8 November 2023 (UTC)[reply]
Grid engine will shut down on December 14th, tool will stop working[edit]
For me, visiting the Toolforge site or clicking the tool on the sidebar results in a screen saying "Wikimedia Toolforge Error" BhamBoi (talk) 23:41, 21 January 2024 (UTC)[reply]
This link has a volunteer in April 2023 noting that "Migrate remaining tools off Gridengine" is "in progress" here: https://phabricator.wikimedia.org/T313405 (and still in progress with regards to the popular and unique CropTool), while the "GridEngine" was noted on 22 January by fnegri as Toolforge: Decommission the Grid Engine infrastructure.
Question: I'm not technically astute, but shouldn't the "in progress" tool migration off the GridEngine be completed or "closed" before "decommisioning" that GridEngine?
@Jmabel to be completely honest, it's hardly possible to fix this problem in such a short time. It's extremely difficult that WMF will overtake the development of CropTool, as well as postponing the deprecation of the engine. Sannita (WMF) (talk) 12:28, 25 January 2024 (UTC)[reply]
@Sannita (WMF): have you (or anyone you know of) heard anything from Dan on this? I'm wondering whether we should presume he is working on this or if it would make more sense to presume that the tool is abandoned. - Jmabel ! talk18:59, 25 January 2024 (UTC)[reply]
Dan says, "On Toolforge, I'm trying to get djvu working in CropTool again after having moved to kubernetes, but having a hard time. There's no compilers in the php7.4 image, so I was recommended to try the rub27 image. I was able to compile things there, but not to get the binaries to run in the php7.4 image due to missing shared libraries. It's probably possible to create fully standalone binaries that don't depend on shared libraries, but it's a bit beyond my knowledge (I tried adding a --disable-shared flag). It would be very helpful if compilers could be added to the php7.4 image, what's the process for requesting that?" https://wm-bot.wmcloud.org/logs/%23wikimedia-cloud/20220721.txt
@Tuválkin: I understand your frustration, but the fact is that WMF did not create this tool and the team Sannita works with have never been formally asked to be responsible for it. Yes, it would be nice to have paid staff with a general responsibility to support tools for Commons. No, that staff does not exist. I don't know your background, but anyone who's worked in the software industry would say that there are few organizations where anyone much below VP level has the authority to take on a sizeable project that was not assigned to them and expend resources on it.
The person who seems to have dropped the ball here is danmichaelo, who took on this responsibility and seems to have let go of it without informing anyone that he had done so. I believe that as recently as October everyone presumed he was on top of this and would provide a timely solution, and even when we got an extension in early December to buy time, the general presumption that was that we were buying time for him to complete this task. For all I know, he might yet plan to fix this, but if so he is sure not letting anyone know what is going on, and clearly at this point we have to presume he will not do this. I've posted a note at the Village pump hoping to find someone who will at least assess the task, if not take it on.
In the larger picture: yes, this situation where individual volunteers take on responsibility for a tool, with no management structure, not even mutual management by peers, is insane, and I've said so before. We keep having broken tools and having to scramble to even work out who might solve the problem. As recently as October, the tool that propagates {{Move cat}} requests for the Delinker was broken, and the only reason it got fixed was I ran into someone at WikiConference North America who was able to make the needed fix then and there, but had no interest in taking over responsibility, and warned that the tool will probably break again in a matter of months because of continual changes in the operating environment. And, as far as I know, nothing ever went any further, so it will break again. - Jmabel ! talk04:01, 29 January 2024 (UTC)[reply]
Thanks, Jmabel. I replied to him below. I understand ths situation, but we either make a huge stink and get this fixed now, or we won’t have an integrated image cropper in two weeks time. I don’t blame Sannita nor Danmichaelo nor anyone individually — I blame those who ever thought that migrating to Kubernetes could/should be done without a guarantee that it would be seamess for the user and everything will still work after the change. Accepting that such migrations always have losses, widespread as it is, is totally unacceptable.
As for basic functionalities that are in the hands of individual users, well maybe Mediawiki should be working on integrating them in a the basic package? Image cropping and category moving surely are more important for a wiki to offer than some of the stuff they are currently planning to introduce (I bet there at people there drooling at the prospect of adding so called AI to the next major mediawiki version…).
As far as I remember Danmichaelo was alienated by a decision at the english (?) Wikipedia more than a year ago. Even if something is done to overcome this alienation, it may well be that them has started other activities by now, and I assume it unlikely that them will return and put the effort into croptool, that is needed to keep it running in the long run. So either @Sannita (WMF) makes maintainance a priority of WMF, or a volunteer takes over CropTool or it is a dead tool. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 20:40, 28 January 2024 (UTC)[reply]
If the maintainer (all maintainers if there is more than one) of a tool is inactive, a new maintainer can be assigned (provided there is someone who actually wants to become the maintainer). In worst case someone could do a fork of the tool (povided someone wants to do a fork and become its maintainer). C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 00:14, 29 January 2024 (UTC)[reply]
"I believe that as recently as October everyone presumed he was on top of this and would provide a timely solution, and even when we got an extension in early December to buy time, the general presumption that was that we were buying time for him to complete this task."
that's certainly not true. anyone who has tried to understand problems croptool has, or even contribute to the code, would have visited the github repo and found out that Dan has probably proactively stopped working on this for a few years already. i dont know the reason, but i've seen C.Suthorn and also other users talking about an incident/conflict/... that drove Dan away.
the blame should certainly be on the website development. on one hand, a widely used functionality has to remain maintained solely by volunteers for a decade. on the other hand, wmf cries for money every single year and has stacked up hundreds of millions.
volunteers are volunteers. they can stop working however they like and dont have any responsibility and dont have obligation to tell anyone.
@RZuo: maybe some people knew Dan had "left the building" but I sure didn't. I don't remember seeing any posts saying "no one seems to be maintaining CropBot, is someone interested in taking it over" prior to my posting that on the Village pump yesterday, when I became aware of the situation. If others knew, it would have been wise to bring it up and seek a solution.
Are there other important tools that you believe have been abandoned? The only other one I'm aware of is the one that handles "move cat" for the Delinker. - Jmabel ! talk19:04, 29 January 2024 (UTC)[reply]
@Tuvalkin I understand the frustration over the lack of maintenance of a tool that I used too as a volunteer, but I can't do anything but repeat that there is hardly the chance that WMF can step in, especially with such a short notice. WMF taking over tools maintained by the community -- this tool, as well as any other tool -- would require a major decision from top management, as @Jmabel correctly notes, since we're talking either understanding how a tool not developed by insiders works or re-do it from scratch. Either way it's going to take time, effort, and in the end money I'm in no position whatsoever to commit (for as much as I would like, and I can tell that I would like it very much). This is a periodical discussion within and with the Foundation, and my unfortunate position is the one I'm in: telling people that WMF cannot do anything for the moment, and that I will try to pass it on to the higher-ups that we need to take a decision on it for the next fiscal years (plural intended). I hope this clarifies my position, and that my options are unfortunately limited to the extreme. Sannita (WMF) (talk) 09:49, 29 January 2024 (UTC)[reply]
You job as Community Liason is to keep the editing community feeling happy about the WMF. Are we happy? We’re not. So, either do your job, or quit. (I’d quit, if I were you. I quit cushier jobs for worst bosses. I’m poor now, but at least I’m not coding for scamming crooks nor for major polluters.)
Don’t give us that company line about not wanting to step on the toes of the user community who’s sovereign in their own tool management. The WMF certainly didn’t feel that way about MediaViewer and VisualEditor and all that nonsense you forced on us.
Besides, nobody’s asking the WMF to create nor mantain an image cropping tool: We’s asking the WMF to be able to migrate instrastructure without jeoperdizing existent functionalities. It’s not to much to ask, it’s the lowest possible bar, and it’s time the WMF leadership understands that the «break everything» philosophy doesn’t cut for a mature wiki ecosystem. If they rather be disruption brats, they should quit and join Musk somewhere cozy — we’ll easily elect someone better.
(Also, fix Global Login already? It’s been 10 years. I’m typing this and the preview shows my IP, while in other windows I’m logged in. Can you be less incompetent?)
Thanks for your attention on this problem! I think stating that it is too soon a deadline for WMF to help is true, and I definitely understand the difficult situation you are in. However, I do think the tool is widely used by the userbase (I use it daily or close to it) and should be considered a top priority by WMF. I think it should be brought to leadership as such, and hopefully you can find a new developer to work on the tool, even if it is after the tool expires next month. If necessary, I think putting a bounty on this type of problem in a developer community, like StackOverflow, can be helpful. The technical issues at hand appear fairly complex. --Engineerchange (talk) 15:58, 29 January 2024 (UTC)[reply]
@Engineerchange People involved with the GridEngine deprecation on Toolforge already know about this situation, I made sure of it. I will keep an eye on the situation, and I will help -- in my volunteer capacity -- to try to find someone who can support the tool for the foreseeable future. Sannita (WMF) (talk) 16:44, 29 January 2024 (UTC)[reply]
"djvulibre, imagemagick and ghostscript" are missing in Kubernetes (k8s).
i think the first step we should take is making imagemagick work. that will make croptool work for images. dont care about the djvu and pdf for now.
or as Dan said, "could probably do without imagemagick if I used built-in php methods, but it requires a small rewrite". someone good at php can rewrite the code to do without magick. RZuo (talk) 07:16, 29 January 2024 (UTC)[reply]
May I take it that besides imagemagick, it also lacks graphicsmagick? Because for simple purposes they are more or less interchangeable, and it would be trivial to switch from one to the other. - Jmabel ! talk
i've only used "cPicture [Jürgen Eidt] (Windows 10+) - Windows Photo Explorer, supports JPEG 9" which is ok, except two problems: i dont know how to zoom in while setting the frame to crop; an intermittent popup problem.--RZuo (talk) 07:02, 29 January 2024 (UTC)[reply]
You mean this as an alternative way to keep the existing tool and workflow, yes? (And not as a separate standalone piece of software, I mean.) -- Tuválkin✉✇15:57, 29 January 2024 (UTC)[reply]
Hello all! A bit late to the discussion, but I bring some good news. The first one you already know, someone stepped in for the migration of CropTool from GridEngine to Kubernetes, and we all thank them for it!
The other good news is that the team who is in charge of the framework migration confirmed me that an extension of the deadline will be granted to allow the user to complete the migration. Of course, there still is a fixed deadline to switch off GridEngine, that is March 14, so the migration should happen in a reasonable amount of time, but at least some more time can be bought.
More generally, the team confirmed me that tool maintainers who are actively working on the Toolforge migration can receive as well an extension to the deadline, if they ask for it. If they need help during the migration, they can also ask the team for help, by using the "help wanted" tag on Phabricator. For more info, there are also the FAQs about the migration.
On the not-so-bright side, tools that are unmaintained are risking deactivation, unless someone steps in. About this, there is little that we can do.
If you have any questions, please ping me, and I'll try to help out as much as I can. Also, if you know of other similar situations, please list them, so that we can try to find a solution together. Sannita (WMF) (talk) 14:37, 5 February 2024 (UTC)[reply]
I don't think there is a lot I can do here, the PR should be fine to merge (imo). I don't have access to merge or deploy anything right now. Sohom (talk) 14:25, 18 February 2024 (UTC)[reply]
Tool in general seems to be working, but I don't have much luck with the "magic border locator" option. Is it a general issue or just for me? Enhancing999 (talk) 15:28, 5 February 2024 (UTC)[reply]
You are correct. It looks like there is a new release today, and it isn't working. This is probably part of the migration, and apparently this broke. I'd suggest you report it in phabricator. - Jmabel ! talk22:53, 5 February 2024 (UTC)[reply]
File «Karl Alfons Jurasky, Gebiete - Reinberger Linde 01.tif» not found on «de.wikipedia.org».[edit]
Hi I am trying to crop an image but the tool just gives me the error message above after I pasted the URL. The file is available here. So why is it not found?--Marcel Rogge (talk) 17:25, 10 February 2024 (UTC)[reply]
Thank you. Is the CropTool uploading something different from what it shows in the tool a known problem? I'm pretty sure that I've seen this once before. WhatamIdoing (talk) 19:38, 13 February 2024 (UTC)[reply]
@WhatamIdoing: It seems to remove nonstandard rotation commands from the uploads, but sometimes does not preview rotated images correctly. There is too much error in this trial-and-error process for my taste. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 19:51, 13 February 2024 (UTC)[reply]
If memory serves, the problem appeared in the first screen: the CropTool showed it as rotated when it shouldn't have been. I "un-rotated" it (back to what I the original image looked like), told it which parts to crop out, and what it uploaded did not match what was on my screen. WhatamIdoing (talk) 19:54, 13 February 2024 (UTC)[reply]
CropTool is not working with a particular image[edit]
If I try to create a cropped version of this image with CropTool, it gets stuck in the loading screen for a while before coming to a page that says "What to crop? Enter the URL or filename for an image you would like to crop." And if I enter the URL or filename on that page, the same cycle continues. I have not had issues like this with other images so far. Do others have this issue as well, and is there anything that can be done to fix it? Carfan568 (talk) 19:11, 23 February 2024 (UTC)[reply]
I've had miscellaneous failures from it recently. Sometimes if I go back to the file page & try again it works, but it also sometimes fails at the point of saving the image. Lately, I've mostly been downloading to my own machine & using GIMP. Yes, it would be nice if this were properly working.
I've continued having intermittent problems, mostly at the point where it goes into "preview" (or, more to the point, fails to go into "preview"). - Jmabel ! talk17:03, 28 February 2024 (UTC)[reply]
Ja, das ist so gewollt. Wenn ein Bild ein Accessment wie "quality" hat, weigert das CropTool sich, dieses Bild zu überschreiben. Es ist ja dafür ausgezeichnet so zu sein, wie es ist und nicht ein Crop davon. Ein eingebauter Vandalismusschutz. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 06:54, 28 February 2024 (UTC)[reply]
Feature request: cropped pictures from DJVU and PDF files are almost never {{Book}}s themselves[edit]
See the most recent upload by CropTool. It's not a {{Book}}, but it uses the same template. Metadata info will almost always be wrong, but I don't expect this tool to solve this.
Instead, I propose the following: 1) Change {{Book}} for {{Artwork}} when cropping from books. 2) Remove the |Wikidata= parameter, as 100% of the time the Wikidata entity refers to the edition of the book, and not the cropped artwork. 3) Remove PDF/DJVU Files, Book by year and country categories. Other changes would need to be manually done, but this is a great start.
"Enter the URL or filename for an image you would like to crop."[edit]
Intermittently in the past few days, I am seeing the message above when I try to use the CropTool from a Commons file page. I have entered the "URL" as well as the "filename" for the Commons image, but nothing happens. In the recent past, the CropTool performs normally again after an unknown period of time.
Up till today, the back button and try again worked. Now this is failing as described for me as well, and that workaround does not help. - Jmabel ! talk23:08, 17 March 2024 (UTC)[reply]
@Enhancing999.No, it is not about file size. The CropTool is failing right now. I am trying to crop a file that is "normal" size from the United States Department of State.
@Jmabel, your suggestion appeared to work once, but I have repeatedly tried this, but the tool is just not responding. The CropTool continues to show an unusual page that asks,
"What to crop? Enter the URL or filename for an image you would like to crop." I have repeatedly entered the "URL" and CropTool fails, then repeatedly entered the "filename" and CropTool fails. Please, note that this intermediate page does show in green writing below that acknowledges "this file exists on Commons."
@Jeff G., Is the following related to your "timing out" comment? There appears to be some error with the CropTool itself. The problem is intermittent in that it happens apparently anytime for unknown reason(s), but after some unknown time period, the CropTool starts working again.
CropTool has had this particular malfunction, regularly, for the last several weeks.
I have noticed this malfunction occurs during the daytime within the United States. I mention this in case it is a high-demand related issue. If the CropTool maintainer could check incoming requests for cropping, perhaps the tool is "overloaded" and starts to malfunction for volunteers with new requests. Just a guess, but I hope it helps to resolve this issue. --Ooligan (talk) 20:29, 18 March 2024 (UTC)[reply]
@Ooligan: I doubt there is anything Sannita can do here: this is not a WMF thing, it's a volunteer-maintained tool. There could be some specific timeout test that might be changed, but it probably runs deeper. - Jmabel ! talk21:10, 18 March 2024 (UTC)[reply]
@Ooligan We already received requests about this, and unfortunately it's not in the current nor future plans to adopt community-maintained tools. There are a good number of reasons behind this decision, but the main reason is that it would require a lot of time and effort to either understand how a tool works, or to rebuild it from scratch. I tried to advocate for this, and will keep trying, but don't hold your breath waiting. Sannita (WMF) (talk) 18:39, 19 March 2024 (UTC)[reply]
Thank you @Sannita (WMF) for continuing to advocate for positive change.
You wrote that "... the main reason is that it would require a lot of time and effort to either understand how a tool works, or to rebuild it from scratch"
From a volunteer point-of-view, I think of all the 1,000's of hours of time given by volunteers at no cost to the Wikimedia Foundation to create the over 670,000+ cropped images found here at extracted images. I'm guessing most from CropTool use. The "time and effort" you mention that the WMF has a monetary value, for example, the cost per hour for code writers multiplied by the total hours to write a new version of CropTool.
So, the WMF adoption of "community-maintained tools" is an investment that pays dividends in the form of increased productivity for all those valuable volunteers.
Just some information for your next chat with the Wikimedia Foundation representatives or staff. Thanks again. Respectfully, -- Ooligan (talk) 00:05, 20 March 2024 (UTC)[reply]
Shouldn't the WMF POV be whether this is functionality Commons should have or not? Who initially wrote it and whether current staff is qualified or not is secondary. Enhancing999 (talk) 07:07, 20 March 2024 (UTC)[reply]
At some point, I could do a smaller file, but not a large one. Maybe it's also a caching issue. If files gradually fill up memory, at some point no new files can be handled. Enhancing999 (talk) 21:44, 18 March 2024 (UTC)[reply]
@Enhancing999: I concur. In each case, it displays "Please wait while fetching image data and metadata... This might take some time depending on the image size..." and then either functions normally or returns to display "What to crop?" and "Enter the URL or filename for an image you would like to crop." — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:26, 19 March 2024 (UTC)[reply]
I can't get past the authorization steps (jumping back from step 3 to step 2, as listed in the project page). I've used CropTool many times in the past but not for a while, so not sure if this is due to some code changes. Any ideas how to solve this? Joalbertine (talk) 12:14, 18 March 2024 (UTC)[reply]
@Joalbertine: Do you have cross-site scripting enabled, at least for commons.wikimedia.org, croptool.toolforge.org, and www.mediawiki.org? Revealing your browser name and version, and same for your OS, may help. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:43, 18 March 2024 (UTC)[reply]
I don't know, but don't think I changed anything, and it used to work fine. How can I check and change it if necessary? I use Windows 10 Pro and Firefox 123. Joalbertine (talk) 13:41, 18 March 2024 (UTC)[reply]
Bumping thread Ahecht (TALK
.jpg){kind=link}
.jpg){kind=link}
![[2]](https://croptool.toolforge.org/?site=commons.wikimedia.org&title=Albert%20Volkart%20-%20ETH%20BIB%20Portr%2002828%20(Johannes%20Meiner).jpg){kind=link}
.jpg)
.jpg){kind=link}
.jpg){kind=link}
