Motivated by the scenarios described earlier, I would like to specify how I think color management should be controlled by the user. Let me first define some hypothetical GUI elements just so we can express this concisely. (How they will be implemented exactly is not important at this point.) A profile selector (PS) lets the user select between predefined profiles like "sRGB", indirectly defined profiles like "use default" or "use embedded" profile, and explicitly selected (ICC) profiles stored in...
Thanks for your animation experiments. According to https://github.com/python-pillow/Pillow/commit/f84684931d3e3ec0c9f6e1ff263fe7e51ee24013 , if I understand it correctly, a frame has a dict-like memberinfo with maybe a key duration. Maybe that helps understanding how the animation stuff in PIL works. If you feel like improving the image loading algorithm of MComix such that PIL can be used as an additional provider for animated images. that would be great! Also, it should probably go to its own...
I've figured out how to read an embedded profile from a pixbuf For the record (in case this becomes useful in the future), this is how I could read the profile: pixbuf = GdkPixbuf.Pixbuf.new_from_file(path) icc = pixbuf.get_options().get('icc-profile', None) if icc is not None: icc = ImageCms.ImageCmsProfile(BytesIO(base64.b64decode(icc))) and to preserve the profile when coverting a PIL image to a pixbuf: icc = image.info.get('icc_profile', None) if icc: pixbuf.set_option('icc-profile', base64.b64encode(icc))...
For the record: It says that the MR is "merged" now without any issues. No noticable change in the repo compared to before the click.
Try to fix random failure to restore window geometry
It's not merged in the (remote) master yet, is it? It is already merged. If you go to the "Git" tab in the web interface, it will tell you that master is already at [d2e9eb]. Whatever, I will click on that button just to see what will happen.
It's not merged in the (remote) master yet, is it? If isn't, it's probably safe to press the merge button, if that's what you want (although you may get conflicts with your local master branch, if you've merged it there). I don't know how exactly SF works, though, I have mostly experience with GitLab.
Thanks for the separate MR. For some reason, SF still says that I could merge it in the web interface despite having it already merged locally and then pushed. Is it safe to press the "Merge" button in the web interface? Or should I just ignore it and close this MR with status "merged"?
Try to fix random failure to restore window geometry
I'm afraid it won't work. No problem, and thank you for trying. So, I think we'll have to live with hack of changing the priority of the two providers. Or maybe PIL should always be the default provider. And given that image enhancements are applied by converting pixbuf to PIL and back to pixbuf, maybe the conversion to pixbuf could be done later? I would not mind using PIL first, given that it seems more powerful in so many ways. The only real downside I see is how (currently) the conversion to...
I've figured out how to read an embedded profile from a pixbuf, so I'll try to rewrite this. Great, looking forward to it! I'm afraid it won't work. Yes, I can read a profile from a pixbuf created directly from file, and yes, I can also make sure that the profile is preserved when converting a PIL image to a pixbuf. But GdkPixbuf does not support CMYK, it only supports RGB (https://docs.gtk.org/gdk-pixbuf/property.Pixbuf.colorspace.html), and a JPG (or anything else, I assume) is probably converted...
I've figured out how to read an embedded profile from a pixbuf, so I'll try to rewrite this. Great, looking forward to it! I'm afraid it won't work. Yes, I can read a profile from a pixbuf created directly from file, and yes, I can also make sure that the profile is preserved when converting a PIL image to a pixbuf. But GdkPixbuf does not support CMYK, it only supports RGB (https://docs.gtk.org/gdk-pixbuf/property.Pixbuf.colorspace.html), and a JPG (or anything else, I assume) is probably converted...
I've also a trial fix for an annoyance I've been having, where the window geometry fails to be restored apparently at random. If this is not OK I can remove it or create a separate MR. Is that bug related to this MR? Did that behavior occur before any of the changes in this MR? As far as I can see it's unrelated to this MR and it did occur before the changes (but I didn't experience it as much as now that I've been opening/closing MComix multiple times...) The change is so small (basically just resizing...
Thanks for the crash course. The intent, and to some extent the math, is relatively clear, So we are on the same page, which is good. but when it comes to when and how each profile should (or actually is) taken into account, I have the impression it's the wild west, and each program/library does whatever. Also on the same page, unfortunately. :-( I have put the preference in a new tab. Thanks. My experience tells me that there are several different aspects of real-world scenarios to consider: Some...
I've figured out how to read an embedded profile from a pixbuf, so I'll try to rewrite this.
Thanks for the crash course. The intent, and to some extent the math, is relatively clear, but when it comes to when and how each profile should (or actually is) taken into account, I have the impression it's the wild west, and each program/library does whatever. I have put the preference in a new tab. For what it's worth, Gwenview has, as far as I can see, only two related settings: enable/disable color management, and select rendering intent (perceptual/relative colorimetric). I've also added a...
Thanks for the crash course. The intent, and to some extent the math, is relatively clear, but when it comes to when and how each profile should (or actually is) taken into account, I have the impression it's the wild west, and each program/library does whatever. I have put the preference in a new tab. For what it's worth, Gwenview has, as far as I can see, only two related settings: enable/disable color management, and select rendering intent (perceptual/relative colorimetric). I've also a trial...
Unfortunately, no, I'm not knowledgeable in either Pillow or color management... Under those circumstances, your code looks quite impressive! I mean, I know enough to figure out that some CMYK images are displayed wrong, track it down to images with embedded profiles and find a way to apply/use the profile "on the fly" without re-encoding the image. I see. But I still don't understand color profiles and their quirks. I am not an expert on that, either, more like an intermediate, but if we combine...
Unfortunately, no, I'm not knowledgeable in either Pillow or color management... Under those circumstances, your code looks quite impressive! I mean, I know enough to figure out that some CMYK images are displayed wrong, track it down to images with embedded profiles and find a way to apply/use the profile "on the fly" without re-encoding the image. I see. But I still don't understand color profiles and their quirks. I am not an expert on that, either, more like an intermediate, but if we combine...
I'm having a look at it. By the way, the current MR still points to the previous commit. Not sure whether you can update the MR, but you probably should (if you can, that is).
Is it better now? Animations should now work as before (i.e. profile conversion is not available for animations), and toggling the preference should refresh all images. AVIF images do not work for me (Kubuntu 24.04) no matter what, so I cannot test that. Although they work with Gwenview and ImageMagick, so maybe it's just some Python module.
Thanks for the feedback. Unfortunately, no, I'm not knowledgeable in either Pillow or color management... I mean, I know enough to figure out that some CMYK images are displayed wrong, track it down to images with embedded profiles and find a way to apply/use the profile "on the fly" without re-encoding the image. But I still don't understand color profiles and their quirks. I'm not even sure "convert to sRGB" is right, since sRGB is a colorspace and not a profile. I'm quite lost here. Still, for...
Thanks for the feedback. Unfortunately, no, I'm not knowledgeable in either Pillow or color management... I mean, I know enough to figure out that some CMYK images are displayed wrong, track it down to images with embedded profiles and find a way to apply/use the profile "on the fly" without re-encoding the image. But I still don't understand color profiles and their quirks. I'm not even sure "convet to sRGB" is right, since sRGB is a colorspace and not a profile. I'm quite lost here. Still, for...
Thanks for the feedback. Unfortunately, no, I'm not knowledgeable in either Pillow or color management... I mean, I know enough to figure out that some CMYK images are displayed wrong, track it down to images with embedded profiles and find a way to apply/use the profile "on the fly" without re-encoding the image. But I still don't understand color profiles and their quirks. I'm not even sure "convet to sRGB" is right, since sRGB is a colorspace and not a profile. I'm quite lost here. Still, for...
I am sorry for the delay. Your MR looks like a good starting point for proper color management in MComix. You seem knowledgeable when it comes to Pillow and color management in general, so it would be great if you could help us here. I tested your MR a bit and, apparently, toggling the checkbox does not seem to work. Normally, when changing a setting in the prefs, the change is applied immediately. (To work around this issue with the current MR, re-caching images appears to be the minimum necessary...
Thank you for your MR, I will have a look into it.
MR https://sourceforge.net/p/mcomix/git/merge-requests/53/ implements this feature.
Add an option (in preferences dialog) to convert embedded profiles to sRGB
Pillow version check error
Thank you for your report. Indeed, the bug you ran into has already been fixed: [bugs:#138] EDIT: Sorry, I somehow missed the very first line you posted that mentions the fixed bug in question.
Thank you for your report. Indeed, the bug you ran into has already been fixed: [bugs:#138]
After further review, it looks like my version is ancient (2016), not sure why a newer version isn't in the repo, but... Feel free to close/cancel if that is a known thing...
Pillow version check error
fix: Shortcut target name did not match generated ID
fix: Generated WiX IDs possibly too long or could contain spaces
MComix 3.1.1
ChangeLog - MComix 3.1.1
Update: Further observation suggests that only AVIF files are affected. Thus, it might be an issue with a third-party lib. Using Arch Linux here, not sure which package might be responsible. I tried experimenting a bit but could not yet reach a conclusive answer. Any help is appreciated.
Can't view overly large images at 100% zoom
Supported images sometimes fail to load
Installation
RuntimeError on python 3.13.5
Thank you for your bug report. Fixed.
Move multiprocessing initialization out of functions
RuntimeError on python 3.13.5
Reposting because the blank space is missing. try: import pillow_avif except ImportError: pass
“pip3 install pillow-avif-plugin” to display avif.
Add avif support
https://sourceforge.net/p/mcomix/git/ci/master/tree/mcomix/thumbnail_view.py#l101 Currently at line 101 of thumbnail_view.py.
Library crashes frequently
Potential to end up looping until you run off the edge of the array and hit an IndexError traceback, isn't there? Correct, but do note that there is a try in _locate_metadata that would catch this or other forms of file corruption. I'm not completely convinced that returning an incorrect value is better than throwing an exception in the case of corrupt files, although if the purpose of the code had been to validate KFX files a better exception message had certainly been in order. :-) nit: "Unpexpected"...
@ferd617 As it says in that post, you can't download the files directly from Amazon, but you can send them to a Kindle or Android device, and then just transfer them from there. My code explicitly recognizes the file layout on eInk Kindle and can access it directly when mounting the Kindle as a mass storage device. You can also use the Calibre plugin to convert it you a kfx-zip if you like, since that format is also recognized. If you transfer the book to a black&white Kindle and get the files from...
I have no idea if it's even possible to do a normal code review here (how do people put up with SourceForge? It's 2025!), but some notes... kfparser.py # -*- coding: utf-8 -*- ''' Kindle Format 10 (KFX) container parser Based on code from KFX Input Calibre plugin by John Howell ''' import struct def _get_base128(data, offs): result = 0 while True: n = data[offs] offs += 1 result = (result << 7) | (n & 0x7f) if n & 0x80: return offs, result Potential to end up looping until you run off the edge of...
@marcus_c This looks great! I've been sort of vaguely following the saga of Amazon cutting off access to download Kindle content from their site (as opposed to via a physical Kindle device), and the changes to content packaging/DRM -- how is this impacted by Implication of Download and Transfer Removal from Amazon?
I added one more commit to make searching for the metadata container more automatic.
Support for Kindle Format 10 (KFX)
I tried change the Thumbnails size and sometimes make the thumbnail correctly but when go back to my desired size, some other random books cover thumbnailes are corrupted. Is so random, even when before covers were fine, and then are corrupted when close and open the library again. Is not an only zip files, is every zip file.
Corrupted thumbnails in the Library
fix: Add work-around for duplicated entries in Pixbuf.get_formats()
Support CMYK and color profile conversion
Reader failing to load some jxl images
This was done in commit f813e027, however GLib has a function GLib.format_size which is likely a much better way to do it. For starters: It's locale-aware >>> import locale >>> import gi >>> from gi.repository import GLib >>> locale.setlocale(locale.LC_ALL, 'en_US') # US English >>> print(GLib.format_size(312665)) 312.7 kB >>> locale.setlocale(locale.LC_ALL, 'de_DE') # German German >>> print(GLib.format_size(312665)) 312,7 KB >>> locale.setlocale(locale.LC_ALL, 'he_IL') # Israeli Hebrew >>> print(GLib.format_size(312665))...
This was done in commit f813e027, however GLib has a function GLib.format_size which is likely a much better way to do it. For starters: It's locale-aware >>> import locale >>> import gi >>> from gi.repository import GLib >>> locale.setlocale(locale.LC_ALL, 'en_US') >>> print(GLib.format_size(312665)) 312.7 kB >>> locale.setlocale(locale.LC_ALL, 'de_DE') >>> print(GLib.format_size(312665)) 312,7 KB It uses SI units (multiples of 10) by default The current ad-hoc code uses IEC powers-of-2 scaling....
TBH I'd love to see a Qt GUI for MComix. We'll see how things unfold. Right now, I'm still clearing out a large backlog of "TLC needed" for hobby projects tracing back to when time management problems I was already having were exacerbated by COVID bursting onto the scene. As such, any MComix stuff is considered "less than ideal, but it works, so focus on the things that are broken or de facto abandoned". Not sure if PyQt is a better choice than Qt for Python, now that it has official support in Qt6....
TBH I'd love to see a Qt GUI for MComix. We'll see how things unfold. Right now, I'm still clearing out a large backlog of "TLC needed" for hobby projects tracing back to when time management problems I was already having were exacerbated by COVID bursting onto the scene. As such, any MComix stuff is considered "less than ideal, but it works, so focus on the things that are broken or de facto abandoned". Not sure if PyQt is a better choice than Qt for Python, now that it has official support in Qt6....
I'd edit the MR description if I could, but I can't.
Turned out, the changes to RecursiveArchive weren't working right (MComix would launch and just do nothing, sometimes), and they weren't necessary as part of this change anyway. So I've ripped those out, and this MR is now only the commits that add and implement the cache-location preference.
TBH I'd love to see a Qt GUI for MComix. I've kind of grown to hate Gtk, and given that MComix is currently written in very ancient Gtk3, updating it to Gtk4 is probably an equal challenge to just replacing it with something built in Qt. Not sure if PyQt is a better choice than Qt for Python, now that it has official support in Qt6. But it probably doesn't matter much, since for the most part the two projects have been dovetailing towards compatibility, or at least relatively simple porting between...
Using the GTK3 inspector, I can determine that mcomix+status+statusbar (the Gtk.EventBox subclass) has no margin or padding values, but the Gtk.Statusbar contained within it is created with default margins of 6 10 6 10 (using CSS top-right-botttom-left ordering). So if the contents of the statusbar widget become taller, those margins could push out the height of the surrounding container to make room. Ideally we'd want the Statusbar to expand into its surrounding container, if necessary, but without...
@aasa Can you provide an example filename that causes the bottom bar to expand? I don't typically work with non-ASCII filenames, and I'd rather have a "real example" than one I just made up, since I can't be sure that mine will reproduce the problem.
Weeeell... one qualifier on that. It could be that the Gtk.EventBox creates some default padding/margins around the Gtk.Statusbar that allow it to have a more dynamic height than it otherwise normally would. AFAICT EventBox is a Gtk.Bin subclass with full layout support, including spacing adjustments. It's probably worth looking for weirdness along those lines.
Huh. I was expecting this to be about wrapping. If the height of the statusbar is changing based on the character set used in its text contents, I'm not sure how much control MComix has over that. The statusbar is just a Gtk.EventBox with a Gtk.Statusbar embedded in it. Contents are removed by calling Gtk.Statusbar.pop() and added by passing strings to Gtk.Statusbar.push(). MComix never sets, adjusts, or computes the height of the widget. If there's a sizing bug related to the text content, it's...
Configurable temporary path, context-manager RecursiveArchive
It is anti-conventional. Which widely used applications use dynamically sized top or bottom bar? It looks horrible when navigating through directories or image files, and prevents users from using mcomix to comparing images visually (as viewport size become inconsistent). Bottom bar file name looks ugly in case of CJK characters: same font size + extra vertical margin means broken vertical layout. Apparently the text widgets of file names screws up vertical margin for CJK characters. Then the bottom...
It is anti-conventional. Which widely used applications use dynamically sized top or bottom bar? It looks horrible when navigating through directories or image files, and prevents users from using mcomix to comparing images visually (as viewport size become inconsistent). Bottom bar file name looks ugly in case of CJK characters: same font size + extra vertical margin means broken vertical layout. Apparently the text widgets of file names screws up vertical margin for CJK characters. Then the bottom...
It is anti-conventional. Which widely used applications use dynamically sized top or bottom bar? It looks horrible when navigating through directories or image files, and prevents users from using mcomix to comparing images visually (as viewport size become inconsistent). Bottom bar file name looks ugly in case of CJK characters: same font size + extra vertical margin means broken vertical layout. Apparently the text widgets of file names screws up vertical margin for CJK characters. Then the bottom...
If I may ask, what is the problem with the bottom bar becoming larger to accommodate larger font symbols? If the bar was fixed height, the font height would need to decrease instead, leading to decreased readability.
Bottom bar height is not fixed and dependent on file names
Support For Mouse Back And Forward Buttons To Change Pages
Thank you, more translation is always welcome!
Add Simplified Chinese translation to the desktop file
Add Simplified Chinese translation to the desktop file
Why is it a choice between (a) the MComix devs making the change in the project; and (b) you making the change as a local patch you'll have to carry. Because my patchset for MComix would be "How can I rip out everything that has changed since the last Comix release with minimal effort?" (Less "helpful PR material" and more "a private GIMPshop to MComix's The GIMP".) (I'm one of those people who stayed on Comix, despite MComix being available, until the last supported month of the last Kubuntu LTS...
While I AM a Python programmer, I'd rather not be responsible for maintaining my own patchset. That's kind of a false dilemma, though. Why is it a choice between (a) the MComix devs making the change in the project; and (b) you making the change as a local patch you'll have to carry. Option (c) is you making the change, and submitting a Merge Request to the project!
I'm actually inclined to agree with this, to an extent. The current context menu is too busy, and incredibly poorly organized for its actual purpose. The entire "View", "Go", and "Bookmarks" menu are swallowed in there verbatim. Big parts of the "File" menu are as well (and "Preferences" from the Edit menu), though at least they're promoted up a level instead of being at the submenu level. Don't even get me started on the Zoom controls being buried TWO levels deep. Way too much of what's there isn't...
fix: Work around broken pymupdf package on MSYS/MINGW
It certainly seems like a worthwile endeavour to me. Thanks!
Proposal: The CBP file extension and application/x-cbp mimetype
New fix.
This problem has already been resolved with MComix 2.2.0. Please upgrade MComix to a more recent version.
New fix.
Proposal: The CBP file extension and application/x-cbp mimetype
I guess you could try a windows 10 virtual machine? Not sure if it's possible that the issue is Ryzen CPU specific but all the machines I've tested these newer versions of MComix on have Ryzen CPUs. And yeah, sorry I can't do more to help.
I just set up a Wine environment and installed 3.1.0 there. Looks fine, still not able to replicate.
Actually, I do not know what it is like to program in Python on Windows (also considering dependency issues and all), and I do not have a Windows machine available for testing, but I guess it would be far from simple, which is why I am sorry for having bothered you. I wonder whether there is another way to replicate this issue.
I don't know exactly how to do that but if you give me a rundown I can try it.
Thank you for all the information. Let me summarize: Windows, version 2.0.0 or higher (version 3.1.0 also affected, but version 1.2.1 works fine), probably specific to the magnifying glass, probably unrelated to DPI issues, probably unrelated to the image format, not just animation rendering artifacts or anything similar. (Note to self: I just tested with GDK_SCALE=3 which does show yet another bug, but at the same time, it demonstrates that the flickering issue is unrelated.) Is it possible for...