Search found 1147 matches
- 2017-07-28T16:08:43-07:00
- Forum: Bugs
- Topic: [became suggest/request: write PNG as sRGB by deflt for DynamRng&Compat -edit] image gets darker&darker every round-trip
- Replies: 43
- Views: 183954
Re: [proposed solution (please respond): write png files as sRGB by default(EDIT)] image gets darker&darker every round-
In addition, in my opinion, we shouldn't have written a "linear png" to begin with, because (1) this is generally very lossy in terms of decreased dynamic range, and (2) a linear png is incompatible with almost all other software that might read it (including IM 7.0.6 although hopefully n...
- 2017-07-28T13:45:26-07:00
- Forum: Bugs
- Topic: [became suggest/request: write PNG as sRGB by deflt for DynamRng&Compat -edit] image gets darker&darker every round-trip
- Replies: 43
- Views: 183954
- 2017-07-28T11:55:51-07:00
- Forum: Bugs
- Topic: [became suggest/request: write PNG as sRGB by deflt for DynamRng&Compat -edit] image gets darker&darker every round-trip
- Replies: 43
- Views: 183954
Re: [proposed solution (please respond): write png files as sRGB by default(EDIT)] image gets darker&darker every round-
Hear's another test case that I'm using to see what's going on. echo one: im7magick -size 1x1 xc:"#ff8000" txt:- | tail -1 echo one.hdr: im7magick -size 1x1 xc:"#ff8000" one.hdr im7magick one.hdr txt:- | tail -1 echo one.hdr.png: im7magick one.hdr one.hdr.png im7magick one.hdr.pn...
- 2017-07-28T11:07:09-07:00
- Forum: Bugs
- Topic: [became suggest/request: write PNG as sRGB by deflt for DynamRng&Compat -edit] image gets darker&darker every round-trip
- Replies: 43
- Views: 183954
Re: [proposed solution (please respond): write png files as sRGB by default(EDIT)] image gets darker&darker every round-
It appears that the HDR reader is applying the gamma. If I convert rose.hdr to txt, it's dark. So what is happening
is that the PNG is being written in sRGB but labeled with a gAMA=1 chunk. Then the decoder uses the gAMA=1
to convert the image (already sRGB) to sRGB again.
is that the PNG is being written in sRGB but labeled with a gAMA=1 chunk. Then the decoder uses the gAMA=1
to convert the image (already sRGB) to sRGB again.
- 2017-07-27T05:10:41-07:00
- Forum: Users
- Topic: Controlled dithering, 16-bit to 8-bit
- Replies: 7
- Views: 9848
Re: Controlled dithering, 16-bit to 8-bit
Also try "-random-threshold" which is essentially a 1x1 dither (i.e., no dithering)
- 2017-07-21T04:37:57-07:00
- Forum: Bugs
- Topic: Two versions of libpng showing in convert -list format
- Replies: 2
- Views: 5491
Re: Two versions of libpng showing in convert -list format
The first is the version of png.h that was used while building ImageMagick, and the second is the version of libpng that is actually being used at run time. 1.6.29 and 1.6.30 happen to be compatible, so it's not a problem. It's not an ImageMagick bug. There *would* be a problem if it showed incompat...
- 2017-07-20T06:46:12-07:00
- Forum: Bugs
- Topic: rectangles are rendering as trapezoids
- Replies: 7
- Views: 9704
Re: rectangles are rendering as trapezoids
looking at the version string you are absolutely right. I should have noticed that. Just wondering where the (nearly) up-to-date timestamp comes from. Obviously it fooled me... It fools everyone. Is the timestamp related to the distros build date and not the ImageMagick release date? The timestamp ...
- 2017-07-15T18:12:29-07:00
- Forum: Users
- Topic: When resizing it's not using the first images bit depth. Is it possible to read the incoming bit depth and use that?
- Replies: 38
- Views: 34898
Re: When resizing it's not using the first images bit depth. Is it possible to read the incoming bit depth and use that?
IM refuses to do that due to not having a colormap. However, if you use "-sample" instead of "-resize" and omit the -unsharp directive, then it succeeds because the -sample operation doesn't destroy the colormap.
- 2017-07-15T03:38:44-07:00
- Forum: Users
- Topic: When resizing it's not using the first images bit depth. Is it possible to read the incoming bit depth and use that?
- Replies: 38
- Views: 34898
Re: When resizing it's not using the first images bit depth. Is it possible to read the incoming bit depth and use that?
pngcheck says Test_Layer.png is 32-bit RGBA while Test_Layer_200.png is 8-bit palette_tRNs.
Sorry for not answering sooner. I'm not subscribed to Magick++ so didn't see it.
Sorry for not answering sooner. I'm not subscribed to Magick++ so didn't see it.
- 2017-07-13T10:21:13-07:00
- Forum: Bugs
- Topic: Option -type palette results in output error with some pngs
- Replies: 2
- Views: 5821
Re: Option -type palette results in output error with some pngs
Verified that your commands fail. I get reasonable output if I replace "-type palette" with "-colors 255".
I needed to add "-depth 8" to the montage command; otherwise the output was a 48-bit RGB PNG.
I needed to add "-depth 8" to the montage command; otherwise the output was a 48-bit RGB PNG.
- 2017-07-13T10:00:48-07:00
- Forum: Developers
- Topic: PNG eXIF chunk proposal
- Replies: 9
- Views: 21423
Re: PNG eXIF chunk proposal
The eXIf chunk proposal was approved by the PNG Development Group.
I've checked eXIf chunk support into coders/png.c in IM6 and IM7.
I've checked eXIf chunk support into coders/png.c in IM6 and IM7.
- 2017-06-29T09:57:41-07:00
- Forum: Developers
- Topic: PNG eXIF chunk proposal
- Replies: 9
- Views: 21423
Re: PNG eXIF chunk proposal
The eXIf chunk proposal is being voted upon now, in the png-mng-misc @ lists.sourceforge.net list.
- 2017-06-14T11:16:42-07:00
- Forum: Bugs
- Topic: possible bug PNG24: keeping alpha channel
- Replies: 6
- Views: 7975
Re: possible bug PNG24: keeping alpha channel
Glenn, sorry, I am confused. Here I only specify PNG24: and both images have the same alpha channel. The only difference is that one has image texture under the alpha and the other has black under the alpha. So why does one leave the alpha channel and the other remove it? I have answered this in th...
- 2017-06-13T16:32:51-07:00
- Forum: Bugs
- Topic: possible bug PNG24: keeping alpha channel
- Replies: 6
- Views: 7975
Re: possible bug PNG24: keeping alpha channel
Your png32 results have alpha channels with some semitransparent pixels (alpha neither 0 nor 1). I guess "convert" is having difficulty transforming that into PNG24 in which all transparent pixels need to be fully transparent and all of them have to be the same color. Forcing them all to h...
- 2017-06-10T11:34:55-07:00
- Forum: Users
- Topic: Apply standard brightness/saturation/contrast
- Replies: 9
- Views: 16270
Re: Apply standard brightness/saturation/contrast
@fred, thanks for autotone. I just updated an old answer of mine on StackExchange to add a link to it: https://graphicdesign.stackexchange.com/questions/77560/improving-the-quality-of-a-picture-taken-at-night/77593#77593 Almost immediately I got a downvote. Go figure. I guess they didn't like it bei...