There was a problem with timezones east of GMT zone. I was using an unsigned int for "addhours"
but it can be negative. Working on a fix.
Search found 1147 matches
- 2017-08-19T09:07:53-07:00
- Forum: Bugs
- Topic: "Ignoring invalid time value" when writing PNGs
- Replies: 6
- Views: 11316
- 2017-08-18T11:31:06-07:00
- Forum: Bugs
- Topic: Linux png compression issue
- Replies: 30
- Views: 50045
Re: Linux png compression issue
Could you post your two PNG output files somewhere that we can retrieve them
or if you prefer, run "pngcheck -v file.png" on both and post the result here?
or if you prefer, run "pngcheck -v file.png" on both and post the result here?
- 2017-08-14T14:19:16-07:00
- Forum: Consulting
- Topic: PAID: Extract copyright from comment and annotate image
- Replies: 4
- Views: 71407
Re: PAID: Extract copyright from comment and annotate image
This does not seem to work with a PNG image that contains a tEXt chunk with copright. The copyright line does show up in the output of identify -verbose as a Copyright property. Properties: Copyright: � 2013,2015 John Cunningham Bowler date:create: 2017-08-14T17:12:35-04:00 but does not show up in t...
- 2017-08-14T13:12:01-07:00
- Forum: Bugs
- Topic: "Ignoring invalid time value" when writing PNGs
- Replies: 6
- Views: 11316
Re: "Ignoring invalid time value" when writing PNGs
It was a temporary glitch, due to some timestamps having the offset from UTC recorded as "Z" instead of "[+-]hh:mm", in IM-7.0.6-6 and 6.9.9-6.
- 2017-08-03T19:16:20-07:00
- Forum: Bugs
- Topic: PNG 'tIME' chunk not in UTC
- Replies: 2
- Views: 7416
Re: PNG 'tIME' chunk not in UTC
Fixed. I added "addhours" and "addminutes" to the scan of "date", and added
that to the existing hours and minutes. Needs more work to handle February
28 on leap years, though.
that to the existing hours and minutes. Needs more work to handle February
28 on leap years, though.
- 2017-08-03T16:46:51-07:00
- Forum: Bugs
- Topic: PNG 'tIME' chunk not in UTC
- Replies: 2
- Views: 7416
Re: PNG 'tIME' chunk not in UTC
coders/png.c, line 8178, write_tIME_chunk(), gets the time from time_t ttime; time(&ttime); On my Ubuntu platform, "man 2 time" claims that it returns time in UTC. However, I confirm that a PNG image created at 19:54 EDT gets a tIME chunk with 19:54 UTC. The date:create property comes ...
- 2017-07-30T16:53:18-07:00
- Forum: Bugs
- Topic: "magick nofile output.png" is too verbose
- Replies: 1
- Views: 4497
"magick nofile output.png" is too verbose
This is a followup to a complaint on the Kudos and Rants Forum. IM7 is too verbose when it can't find a file, as in magick nothing.jpg output.png Im6 only emits 2 lines while im7 seems to get into "property.c" with invalid input, and emits about 3 more error messages. Also, "magick co...
- 2017-07-30T08:21:12-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: 184421
Re: [proposed solution (please respond): write png files as sRGB by default(EDIT)] image gets darker&darker every round-
In the related bug report I've fixed coders/png.c so that pixels survive multiple round trips between HDR and PNG formats.
- 2017-07-29T18:10:43-07:00
- Forum: Bugs
- Topic: [glennrp fixd IM7 to git] reading linear png (GAMA=1) sets sRGB (nonlinear colorspace) but should set RGB (linear) instd
- Replies: 2
- Views: 6158
Re: reading linear png (GAMA=1) sets sRGB (nonlinear colorspace) but it should set RGB (linear) instead
I've pushed a change to the IM7 git repo The "one" demo works nicely; the pixel values survive the round-trip PNG->HDR->PNG->HDR: one: 0,0: (65535,32896,0) #FFFF80800000 srgb(255,128,0) one.hdr: 0,0: (65535,32768,0) #FFFF80000000 rgb(100%,50%,0%) one.hdr.png: 0,0: (65535,32896,0) #FF8000 r...
- 2017-07-29T17:40:39-07:00
- Forum: Bugs
- Topic: [glennrp fixd IM7 to git] reading linear png (GAMA=1) sets sRGB (nonlinear colorspace) but should set RGB (linear) instd
- Replies: 2
- Views: 6158
Re: reading linear png (GAMA=1) sets sRGB (nonlinear colorspace) but it should set RGB (linear) instead
The png reader is setting gamma to1.0 but neglects to reset the image colorspace. That would be a bug that needs to be fixed.
I'm testing a patch now.
I'm testing a patch now.
- 2017-07-29T13:32:30-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: 184421
Re: [proposed solution (please respond): write png files as sRGB by default(EDIT)] image gets darker&darker every round-
Am I missing something? Wasn't there an issue about IM not doing a round trip correctly? Not reading linear PNG files correctly? Has that been resolved, or is someone investigating? It's still open as far as I am concerned. Incidentally, the one.hdr.png file from my demo does happen to be 16-bit (4...
- 2017-07-29T09:04:57-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: 184421
Re: [proposed solution (please respond): write png files as sRGB by default(EDIT)] image gets darker&darker every round-
There's no harm in writing 16-bit sRGB PNG images.
- 2017-07-29T05:20:02-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: 184421
Re: [proposed solution (please respond): write png files as sRGB by default(EDIT)] image gets darker&darker every round-
... And they recommend exporting images as 8-bit sRGB for use by the world, ... Okay, so, at least if we're writing an 8-bit per sample PNG file would you agree that sRGB should be the default, rather than whatever-colorspace-the-image-just-so-happens-to-already-be-in-for-whatever-reasons? The libp...
- 2017-07-28T17:27:16-07:00
- Forum: Users
- Topic: Controlled dithering, 16-bit to 8-bit
- Replies: 7
- Views: 9896
Re: Controlled dithering, 16-bit to 8-bit
Right, "random-threshold" reduces the image to black and white pixels. I think there's a way to random-dither each channel to get an 8-color image. But no way to get a 256-color image with it.
- 2017-07-28T17:22:36-07:00
- Forum: Users
- Topic: Clarification on use of colours and depth in IM
- Replies: 12
- Views: 12136
Re: Clarification on use of colours and depth in IM
Use -sample instead of -resize if you don't want to add interpolated colors.