Activity for Reuben Thomas
-
Reuben Thomas posted a comment on ticket #755
Great stuff! I really appreciate the time and effort you put into this issue, as well as GM in general.
-
The image was AI-generated, I believe, so the dirtiness is not surprising. The ImageMagick issue https://github.com/ImageMagick/ImageMagick/issues/8200 has not been updated since the day I filed it. I'm not clear whether the promised change was merged, but there's nothing to indicate that it has been.
-
Thanks for this. As you can probably tell, the project is somewhat moribund at present. I hope to find time to build on some of the excellent work that has been done elsewhere to revive it soon; but in the mean time there are forks such as https://codeberg.org/sox_ng/sox_ng/ that are being actively worked on.
-
Thanks, that's very interesting background. I hadn't realised that IM writes only up to 16 colours; I checked, but I can't see any mention of it above. The IM folk are in the process of improving PNG8 output; see: https://github.com/ImageMagick/ImageMagick/issues/8200 but at the same time changing what PNG8 means as far as IM is concerned, I guess.
-
I think this issue can be closed, at any rate (or maybe you're waiting until the next release?): anyway, GM no longer produces an invalid PNG in this case.
-
Yes, I see the warning. What I didn't realise is that the original image has those speckles; it seems then that the behavior is quite reasonable; sorry!
-
Here's the image attachment.
-
I attach the processed image, in case it's different from what you're getting. Do let me know if it's not obvious what's wrong with it. (My claim, recall, is that the conversion to indexed PNG is now buggy.)
-
Also, on closer inspection the image produced seems to have some bogus black pixels which should "clearly" be transparent, i.e. they were completely transparent in the original, no hint of color. Do let me know if you me need to attach the processed image, or if you're seeing something different!
-
Better (non-binary) transparency in indexed PNGs
-
Also, on closer inspection the image produced seems to have some bogus black pixels which should "clearly" be transparent, i.e. they were completely transparent in the original, no hint of color. Do let me know if you need to attach the processed image, or if you're seeing something different!
-
That seems to work fine, many thanks! Did you come to a conclusion as to whether libpng should in theory allow full transparency in indexed format files?
-
Many thanks! I'll give it a go.
-
I think I'm catching up: you're saying that libpng only allows binary transparency in 8-bit indexed (type 3) images, despite the PNG spec apparently not insisting on this? I had a quick look at the libpng code to see if I could confirm or deny this, but it's too complicated for me to understand (I am not an image format expert!).
-
I believe that there's no problem in principle having 256 transparent colours in this format, so the binary transparency appears to be a limitation of IM's algorithm (perhaps in order to reduce the size of the image?) rather than the PNG format. In other words, could GM simply avoid the complexity and produce a PNG8 with regular transparency?
-
Thanks for the analysis! Given that even ImageMagick's conversion is not great (specifically, the binary transparency, which the user who found this issue complained about!), rather than do something even simpler, it might be reasonable to simply error out when this conversion is requested in GM.
-
Thanks for the rapid response! I attach the original PNG in a Zip (and I confirmed that it differs from the version I attached earlier when downloaded again from SF). When I run pngcheck on the original: OK: ABCD-192.png (192x192, 32-bit RGB+alpha, non-interlaced, 76.5%). When I run pngcheck on the version produced by the GM command above: ABCD-192-indexed.png CRC error in chunk tRNS (computed a93c6334, expected f7e8dd9b) ERROR: ABCD-192-indexed.png
-
Converting to indexed PNG produces invalid file
-
The standard way to have an explicit "et al" in BibTeX is to use the pseudo-author "others", which is documented as point 5 on p. 12 of the BibTeX manual.
-
-
-
-
Thanks, merged!
-
Always composite image to account for alpha transparency
-
Merged; thanks!
-
I think my preference would be to remove xzgv's "native" thumbnail functionality altogether. Neither zgv nor xv seems to be maintained, and neither is in Debian, so cooperation with other apps is no longer a feature. This leaves "standalone thumbnails not depending on DBus". I did have a look to see if there was a standalone implementation of the standard (i.e. in a library) that doesn't require DBus; but I can't find such a thing. Or does e.g. Nautilus or Dolphin update thumbnails? Does any standalone...
-
Merged, thanks!
-
Add a mnemonic to the `Images Only` menu entry
-
Add a mnemonic to the `Images Only` menu entry
-
Merged, thanks! (Not sure why, the commit mentioned here is not the current version, but I found that and applied it.)
-
Mark the `image-bigness-threshold` option as deprecated
-
Thanks, merged!
-
Remove all mentions of thumbnails being compatible with GIMP
-
Remove all mentions of thumbnails being compatible with GIMP
-
Thanks, merged!
-
Compare ratios as floating-point when determining panorama orientation
-
Remember our own current path location, before symlink resolution
-
Thanks, I agree with your method and I've now merged the latest version of the changes.
-
Remember our own current path location, before symlink resolution
-
Thanks, merged!
-
Calculate the scrolled window border thickness at runtime
-
Thanks, good catch!
-
I agree that it's nice to support the standard. But I also agree that the use of two different thumbnailer systems would be confusing. I don't think depending on D-Bus (or specifically libdbus) would be a problem, but obviously it would take some work to use the Thumbnailer service.
-
Thanks for tackling this problem! It's not easy. I see in tnupdate.c the following code: /* save old cwd to avoid depending on chdir("..") to be sane :-) */ old_cwd=getcwd_allocated(); Should this code also use your new functions? Or, would it be possible not to call chdir? Obviously, a lot of the code is organized around the idea that the current directory changes, but instead xzgv could simply track which directory it's in without actually chdir-ing. Then, it would not need to resolve symlinks,...
-
Merged; thanks!
-
Resume loading thumbnails after being interrupted
-
Merged; thanks! Thank you very much for your recent fixes; do let me know when they're complete and I'll make a new release at once.
-
Make the `interpolate` option effective again
-
Make the `interpolate` option effective again
-
Thanks; merged!
-
Silence `misleading-indentation` warning from gcc
-
Silence `misleading-indentation` warning from gcc
-
Use `override` when appending to `CFLAGS` and `LDFLAGS` in Makefile
-
Use `override` when appending to `CFLAGS` and `LDFLAGS` in Makefile
-
Thanks for this; merged!
-
INSTALL: require specifically GNU Make
-
Typo on web site
-
By the way, tuxpaint-config calls paperinit() before other functions already, so there's nothing to fix there.
-
By the way, tuxpaint-config calls initpaper() before other functions already, so there's nothing to fix there.
-
Fix initialization of libpaper
-
Typo in ved web page
-
Subscribing to this bug.
-
autopygmentize: various improvements
-
autopygmentize: check list of MIME types unknown to pygments
-
Minor updates to autopygmentize.
-
autopygmentize: update for pygments 2.0
-
I notice that the patch does not work cleanly in a message, so I've added it as a separate attachment.
-
I notice that the patch does not work cleanly in a message, so I've added it as a separate attachment.
-
Cannot change font for literallayout without setting literal.class parameter
-
Inability to clone repository
-
Support installation under different prefixes
-
Ping! If you let me know whether any further documentation is required, I can update the patch. It would be good to have dnsexit support in a release!
-
Fixed bug 7 in Sourceforge (memory leak). Also applied and checked proposed patch 2 (when renaming, put the same name as base option)
-
Fixed bug 4 in Sourceforge (no thumbnails)
-
Some initial steps towards a Gtk+3 port
-
Fix URL in manual
-
Build PDF instead of DVI version of manual
-
Manual: change bug reporting instructions to SourceForge
-
.gitignore: add xzgv.info.gz
-
Bump Makefile version to 0.9.2
-
Use glib file copy/move routines
-
Remove remaining code & docs for gamma, brightness & contrast
-
Update documentation
-
main.c: remove unnecessary Debian bug reference from comment
-
main.c: remove unused variable
-
main.c: remove some unnecessary ifdefs
-
Fix some minor whitespace issues
-
filedetails.c: remove an unused variable
-
Add .gitignore files to doc and src
-
Minor clarifications.
-
Patch from Theodore Ts'o to fix name of info file
-
Clean up GTK-related TODOs.
-
Simplify and fix locale-dependent bug.
-
Trim list of bit-depths in bug reports section.
-
Patch from Theodore Ts'o to fix info
-
No longer allow Space to select and open a picture.
-
Remove specialised readers; just use GDK.
-
Remove logo.
-
Reinstate line-breaking, as Russell says, to allow escaping of lines
-
Remove 8-bit dithering TODO, as 8-bit displays are all but extinct.
1 >
