@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[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[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[reply]
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[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[reply]
Grid engine will shut down on December 14th, tool will stop working[edit]
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[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[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[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[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[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[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[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[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[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[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[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[reply]
.jpg){kind=link}
.jpg){kind=link}
