Pillow
Pillow copied to clipboard
python-pillow
Add support for Windows 1.x/2.x Icon file format
Is your feature request related to a feature request? Please describe.
Be able to view, edit or convert .ICO files from Windows 1.x/2.x.
http://fileformats.archiveteam.org/wiki/Windows_1.0_Icon
Sample file: CARDFILE.ICO opened by ICONEDIT.EXE (attachment below):
The data are the black&white pixels, the grey zones are believed to be transparent.
The icon of the program CARDFILE.EXE (CARDFILE.ICO) can be seen in the taskbar, bottom left, when CARDFILE.EXE is minimized:
and sometimes in the About dialog, specially in Microsoft programs:
According to this website, 1.x and 2.x share same icons:
https://www.howtogeek.com/733912/a-visual-history-of-windows-icons-from-windows-1-to-11/
Describe the solution you'd like
Be able to convert from and to ICO file format (Windows 1.x/2.x). For example from and to PNG, TIFF.
Describe alternatives you've considered
GIMP and ImageMagick don't support it yet:
- https://gitlab.gnome.org/GNOME/gimp/-/issues/9814
- https://github.com/ImageMagick/ImageMagick/issues/6527
Samples:
If we do add support, is cardfile.ico something that can be added to our test suite, and distributed under the Pillow license?
CARDFILE.ICO was designed by Microsoft I think, and it's included with the SDK, but I will provide another sample.
Here's a custom made icon with some screenshots. This one you can include it. The file was created by ICONEDIT.EXE (the official Microsoft app). The gray or Ltgray background is just the parts that are supposed to be transparent (the icons are supposed to support transparency).
PenColor types:
Grid OFF:
Grid ON:
Gray background (default):
Lite Gray background:
I'm not sure what you mean. What is the size of CARDFILE.ICO and CUSTMADE.ICO? If that's not a question that you know the answer to, I can ask a simpler question - are they squares, or rectangles?
They are square, the editor makes them look stretched. they are 32x32 but stored as 64x64 if it's "device independent": http://fileformats.archiveteam.org/wiki/Windows_1.0_Icon
Looking at CUSTMADE.ICO, scaling it down from 64x64 to 32x32 would lose information - there are individual pixel differences that you can't show in a 32x32 space - which doesn't sound good to me.
Do these two PNGs look correct? They include transparency.
I've created PR #7427 with this solution.
I must say I'm a little apprehensive adding support for icons for an operating system that was first released in 1985, last released in 1989 and unsupported since 2001...
Why should we support this?
How widespread is use of these icons 20-40 years later?
Would this be better as a standalone plugin?
What other tools are there for this sort of thing?
I'm all for this based on supporting @superbonaci's efforts alone, but also, I'm not sure if the specifications of the ICO format as it was introduced by M$ in Windows 1.0 are directly related to the age of the Windows operating system. In other words, you wouldn't use Windows 1.0 in production environments today, but I'm not sure that makes it unreasonable to support the ICO format in modern software.
I think the important questions are:
- What are the security and maintenance implications?
- How widespread is use of these icons 20-40 years later? (I agree with @hugovk on this one.)
- Is "cool factor" alone enough?
For me, the answer to the last question is "yes", but I agree we should still perform due diligence.
Looking at CUSTMADE.ICO, scaling it down from 64x64 to 32x32 would lose information - there are individual pixel differences that you can't show in a 32x32 space - which doesn't sound good to me.
Maybe the sample I provided is a device-independent .ico file, just found out that you can choose to save it as Device Dependent or Device Independent, so I'm attaching the two so you can see the difference:
I think the format itself wouldn't need much maintenance, precisely because it has been abandoned, and also because it is relatively simple.
@superbonaci do you have any thoughts on the concerns raised? What led you to create this feature request? Do you believe that your need would be shared by others? If not, are you open to the idea of accepting the code I've written as a file that you can download and import, rather than something that is distributed as part of Pillow? I see that you've also tried to request this functionality from GIMP and ImageMagick - what software do you know of that can actually handle these images?
@radarhere the only software I know of that can read, edit or write Windows 1.x/2.x icons is Microsoft Windows ICON Editor Version 1.01, ICONEDIT.EXE which is included in WINSDK101. And of course updated versions to it before Windows 3.
There may be some Borland software compatible with those older versions of Windows that can do the export to newer icon file format that can't verify it.
If you want to see more of it: STREAM: Porting 16-bit Windows 1.0 Applications to 64-Bit Windows 11
After minute 41 starts talking about the icons.
Does you code handle both device dependent and independent formats?
I've updated my PR to read device-dependent, device-independent and "both" formats. It saves in device-independent format.
Did you have any thoughts on the other questions raised? Why this would make a useful addition to Pillow, and not just code that you import for your software?
I would argue that this is in theory, beneficial to the world in the same way that a service like https://archive.org/ is. In practice, who knows.
Off hand, I find it interesting to think about processing a large number of these device-dependent images and outputting device independent images and to clarify, "independence" is about proper color scheme rendering? Anything else?
Lastly, while I'd love to see this go in to 10.1.0, there is probably no urgency at least not from me, so maybe we let @hugovk contemplate for the Jan 1 2024 release.
Are you contemplating one-way only conversion, that is ICO to PNG/TIFF only, or both ways?
I've updated the issues in GIMP and ImageMagick so they are aware of the two formats, device dependent and independent.
I'm adding the 3 icons generated by the 3 methods available in the Microsoft editor. Basically the 2nd and 3rd method generate the same file (in this case), no idea why it's even duplicated. There must be some use case that we don't know:
$ md5sum *.ICO
cf47b1f99891e5293c548c127418040c *CARDFILE.ICO
83da42642cd6ce51eb054760121960f2 *CUSTMADE.ICO
88a680006a4f89e9fad4e5a3d52d09b4 *DEVDEP.ICO
83da42642cd6ce51eb054760121960f2 *DEVIND.ICO
83da42642cd6ce51eb054760121960f2 *OPT1.ICO
88a680006a4f89e9fad4e5a3d52d09b4 *OPT2.ICO
88a680006a4f89e9fad4e5a3d52d09b4 *OPT3.ICO
Thanks, but as you can see from your checksums, OPT2 and OPT3 are identical - they are both "both", so that doesn't provide any new information.
Are you contemplating one-way only conversion, that is ICO to PNG/TIFF only, or both ways?
The PR would allow you to read Windows 1 icon files and save to them as well. It just only saves to device-independent Windows 1 icon files. So you can convert images from PNG to Windows 1 icons, from Windows 1 icons to PNG, open Windows 1 icons, rotate them or some other transformation, and save back as Windows 1 icons, anything you like.
to clarify, "independence" is about proper color scheme rendering? Anything else?
Based on http://fileformats.archiveteam.org/wiki/Windows_1.0_Icon, device-independent is at 2x resolution, and device-dependent is 1x. "both" has 1x and 2x. There is no difference in colors.
What other tools are there for this sort of thing?
In response to @superbonaci's request, ImageMagick has now added support for this format - https://github.com/ImageMagick/ImageMagick/discussions/6670
What other tools are there for this sort of thing?
In response to @superbonaci's request, ImageMagick has now added support for this format - ImageMagick/ImageMagick#6670
Fantastic. Can't wait to make some tests for compatibility.
It has been six months since the PR was created, and it hasn't been merged for three releases.
If it's being put off because of all the other Pillow development that goes on, no problem, but I don't think that's the case. It would seem it is being put off because there isn't an appetite for this functionality. If that is the case, shall we just close this issue?
I don't see a strong need for this: https://github.com/python-pillow/Pillow/issues/7320#issuecomment-1741270231.
If anything, I'd go the other way and review some of our other image formats to see if they're obsolete and no longer needed (they could have a longer than usual deprecation, and restored if we got feedback of widespread use).
@superbonaci if that is a note to yourself, ok, but the intention of the last few comments from our side is that this is not something that will be done.