Search found 1147 matches
- 2017-06-10T09:00:31-07:00
- Forum: Kudos and Rants
- Topic: Why is there an off-topic add at the top of each imagemagick.org page?
- Replies: 13
- Views: 138101
Re: Why is there an off-topic add at the top of each imagemagick.org page?
I see them if I visit as guest but not while logged in. Lately the ad has contained a huge green DOWNLOAD button which installs some sort of crapware, not ImageMagick.
- 2017-06-10T08:58:45-07:00
- Forum: Users
- Topic: identify and cr2 raw takes ages
- Replies: 12
- Views: 10669
Re: identify and cr2 raw takes ages
Have you tried using a Q16 build instead of Q32?
- 2017-06-07T12:22:57-07:00
- Forum: Users
- Topic: Apply standard brightness/saturation/contrast
- Replies: 9
- Views: 16550
Re: Apply standard brightness/saturation/contrast
Here are comments by me and fmw42 on the StackOverflow instance of this question: Have you tried the "-normalize" option of ImageMagick? There are more complex methods that produce better results, but you might like the result as a first cut at fixing them. – Glenn Randers-Pehrson yesterda...
- 2017-05-31T14:13:04-07:00
- Forum: Developers
- Topic: PNG eXIF chunk proposal
- Replies: 9
- Views: 22199
Re: PNG eXIF chunk proposal
Thanks for the feedback. We're proceeding with the eXIf chunk proposal, keeping the thumbnail if it's present.
- 2017-05-29T13:31:23-07:00
- Forum: Developers
- Topic: PNG eXIF chunk proposal
- Replies: 9
- Views: 22199
Re: PNG eXIF chunk proposal
I know what you mean about the jpg thumbnail being out of sink. Out of interest how would a create private chunk in imagemagick? Look at the "caNv" chunk support in coders/png.c; this is a fairly simple example of using a user read function to understand a private chunk. There's also code...
- 2017-05-29T10:26:53-07:00
- Forum: Developers
- Topic: PNG eXIF chunk proposal
- Replies: 9
- Views: 22199
Re: PNG eXIF chunk proposal
The troublesome part is maintaining the thumbnail when the image is edited. We dealt with that in the chunk proposal by mentioning that the thumbnail might be out of sync with the main image. Specifically, the current draft says "While encoders may choose to update them, there is no expectation...
- 2017-05-29T08:10:07-07:00
- Forum: Users
- Topic: Help me to understand below CLI
- Replies: 3
- Views: 8353
Re: Help me to understand below CLI
I was saving image as jpeg using first CLI so it would remove transparency. That's not a great way of removing transparency, due to the lossy conversion to JPEG. There are ways of removing transparency via "-alpha " options, but if you like the simplicity of converting to an opaque image ...
- 2017-05-28T09:01:12-07:00
- Forum: Developers
- Topic: PNG eXIF chunk proposal
- Replies: 9
- Views: 22199
PNG eXIF chunk proposal
During January and February 2017 the PNG Development Group discussed a proposed eXIf chunk for storing the Exif profile. See http://www.simplesystems.org/png-group/proposals/eXIf/ The PNG group discussion has lapsed without action on the proposal. The proposal was pretty simplistic: just copy whatev...
- 2017-05-24T07:41:42-07:00
- Forum: Bugs
- Topic: macOS, PNG conversion gives "Abort trap: 6"
- Replies: 2
- Views: 5709
Re: macOS, PNG conversion gives "Abort trap: 6"
Are you sure you are running ImageMagick's "convert"? With version 7.0.5 it's "magick" or "magick convert" instead.
- 2017-05-20T17:18:21-07:00
- Forum: Developers
- Topic: MozJPEG library in ImageMagick build
- Replies: 3
- Views: 21217
Re: MozJPEG library in ImageMagick build
What does MozJPEG offer that libjpeg doesn't? As far as I know, MozJPEG is just a fork of libjpeg.
- 2017-05-18T10:10:14-07:00
- Forum: Bugs
- Topic: PNG32/PNG64 has broken.
- Replies: 4
- Views: 8865
Re: PNG32/PNG64 has broken.
Confirmed that this bug exists in 7.0.5-0 and as far back as 7.0.1-0.
Version 6.9.8-5 produces a correct png32 but a fully transparent png64.
Version 6.9.8-5 produces a correct png32 but a fully transparent png64.
- 2017-04-30T08:22:18-07:00
- Forum: Users
- Topic: "Optimized" image heavier (bigger file size) than the original
- Replies: 14
- Views: 15381
Re: "Optimized" image heavier (bigger file size) than the original
Your original file, according to "identify -verbose" has "Quality 69 (approximate)". The "approximate" means that the quantization tables used weren't exactly those used by ImageMagick, so the recompression won't be exactly the same. It's not a mistake but simply a fact...
- 2017-04-28T12:55:50-07:00
- Forum: Users
- Topic: "Optimized" image heavier (bigger file size) than the original
- Replies: 14
- Views: 15381
Re: "Optimized" image heavier (bigger file size) than the original
Is there any way to preserve de multiplicity? I mean, trim in "8x8 blocks" steps, to avoid to do new blocks. I don't mind trim a little less pixels if the file size will be better. I don't know of a really simple way, but I've done it lots of times, for this very reason. It involves some ...
- 2017-04-27T11:43:41-07:00
- Forum: Users
- Topic: "Optimized" image heavier (bigger file size) than the original
- Replies: 14
- Views: 15381
Re: "Optimized" image heavier (bigger file size) than the original
Also bear in mind that when the -trim operation doesn't cut off an exact multiple of 8 columns or 8 rows, the image gets re-quantized into new 8x8 blocks (or 16x16 blocks, if sub-sampling), which can cause new colors to be created (by default, sub-sampling happens when the requested quality is less ...
- 2017-04-14T07:35:50-07:00
- Forum: Bugs
- Topic: Corrupt input may lead to crash
- Replies: 3
- Views: 9769
Re: Corrupt PNG leads to SIGABRT
The test file actually contains a corrupt PPM file with the .png extension. studio> od -c corrupt.png | head 0000000 P 6 \n # S A N E d a t a f 0000020 o l l o w s \n 2 7 5 2 4 6 0 4 0000040 \n 2 5 5 \n 377 377 377 377 377 377 377 377 377 377 377 0000060 377 377 377 377 377 377 377 377 377 377 377 3...