Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

PNG image problem: encountered an unsupported criticial chunk type "iDOT"

214 views
Skip to first unread message

J. van den hoff

unread,
Nov 18, 2017, 1:40:23 PM11/18/17
to
with certain PNG files (screenshots generated on a Mac) I see the following with 8.6.7:

executing

image create photo -file "Screen Shot 2017-11-18 at 19.26.37.png"

leads to the error message

encountered an unsupported criticial chunk type "iDOT"

while it works just fine with other PNG files (e.g. when using imageMagick to convert the above screenshot to another PNG file...)

also, after 'package require img::png' the problem goes away.

my understanding ist that PNG support is build into the Tk core (and in fact PNG files usually _can_ be processed) but it seems that this is implemented differently than in the "Img" package (and seems, then, to have a bug...)?

question am I overlooking something or is this a bug to report to the Tk developers?

Christian Gollwitzer

unread,
Nov 18, 2017, 2:04:05 PM11/18/17
to
Am 18.11.17 um 19:40 schrieb J. van den hoff:
> with certain PNG files (screenshots generated on a Mac) I see the following with 8.6.7:
>
> executing
>
> image create photo -file "Screen Shot 2017-11-18 at 19.26.37.png"
>
> leads to the error message
>
> encountered an unsupported criticial chunk type "iDOT"

Please create a ticket at core.tcl.tk and attach a small PNG file which
causes this

> also, after 'package require img::png' the problem goes away.

The Img package loads another PNG implementation, which depends on some
(larger) PNG library, while the built-in PNG support was created "from
scratch" to support just enough of PNG what Tk can use.

Christian

J. van den hoff

unread,
Nov 18, 2017, 4:01:27 PM11/18/17
to
On Saturday, 18 November 2017 20:04:05 UTC+1, Christian Gollwitzer wrote:
> Am 18.11.17 um 19:40 schrieb J. van den hoff:
> > with certain PNG files (screenshots generated on a Mac) I see the following with 8.6.7:
> >
> > executing
> >
> > image create photo -file "Screen Shot 2017-11-18 at 19.26.37.png"
> >
> > leads to the error message
> >
> > encountered an unsupported criticial chunk type "iDOT"
>
> Please create a ticket at core.tcl.tk and attach a small PNG file which
> causes this

ok, will do.

>
> > also, after 'package require img::png' the problem goes away.
>
> The Img package loads another PNG implementation, which depends on some
> (larger) PNG library, while the built-in PNG support was created "from
> scratch" to support just enough of PNG what Tk can use.

understood. thanks.

>
> Christian

J. van den hoff

unread,
Nov 18, 2017, 5:03:27 PM11/18/17
to
by the way: img::png has another issue at least under OSX as I've just recognised: the resulting display has the wrong gamma correction or whatever (image way too dark, wrongly saturated colours...) compared to what the Tk internal png-implementation is delivering (for those png where both are able to process the file). any idea where I should direct questions regarding the Img package? the source forge "home page" seems dead as a dodo or am I mistaken? (or is Tk the culprit after all if png images loaded by the internal implementation and loaded by Img::png do look very different in the end?)

Ashok

unread,
Nov 19, 2017, 2:40:11 AM11/19/17
to
The last release of img was Dec 2016 so the project is certainly not
dead. I would suggest logging a ticket at
https://sourceforge.net/p/tkimg/bugs/. The project maintainers are also
listed there so you could send an email via their sourceforge addresses.

/Ashok

On 11/19/2017 3:33 AM, J. van den hoff wrote:> by the way: img::png has

J. van den hoff

unread,
Nov 19, 2017, 10:13:35 AM11/19/17
to
On Sunday, 19 November 2017 08:40:11 UTC+1, Ashok wrote:
> The last release of img was Dec 2016 so the project is certainly not
> dead. I would suggest logging a ticket at
> https://sourceforge.net/p/tkimg/bugs/. The project maintainers are also
> listed there so you could send an email via their sourceforge addresses.
>

ok, will try that. thank you....

Luis Alejandro Muzzachiodi

unread,
Nov 19, 2017, 11:35:02 AM11/19/17
to
It seems that this chunk has been introduced by Apple without documentation. Isn't in the png specification and also, according to some comments(*), is violating the name conventions for publics chunks.

(*)https://stackoverflow.com/questions/33894790/what-is-the-idot-chunk

J. van den hoff

unread,
Nov 19, 2017, 2:06:18 PM11/19/17
to
On Sunday, 19 November 2017 17:35:02 UTC+1, Luis Alejandro Muzzachiodi wrote:
> It seems that this chunk has been introduced by Apple without documentation. Isn't in the png specification and also, according to some comments(*), is violating the name conventions for publics chunks.
>
> (*)https://stackoverflow.com/questions/33894790/what-is-the-idot-chunk

thanks a lot. that's very interesting/helpful. I was not aware of this...

while the fact that Apple is doing this, is annoying in itself and strictly speaking the TK PNG implementation thus is not the culprit, it might be better if it would just ignore that chunk just as libpng based tools seem to do, no?

Donal K. Fellows

unread,
Nov 20, 2017, 12:13:37 PM11/20/17
to
On 18/11/2017 18:40, J. van den hoff wrote:
> question am I overlooking something or is this a bug to report to the Tk developers?

Yes, this is a reportable bug (hopefully you've got a small unimportant
image that triggers this). The bug is that it shouldn't be reported as a
critical chunk as the initial letter is lower case; it ought to have
been interpreted as an ancillary chunk and ignored. (It seems that the
“iDOT” chunk type is some Apple-specific extension that isn't marked as
a proper vendor extension and nobody else knows what to do with it other
that ignore or delete it. Or sabotage it. It's theorised that it relates
to something to do with the screen resolution for HighDPI displays.)

Donal.
--
Donal Fellows — Tcl user, Tcl maintainer, TIP editor.

Donal K. Fellows

unread,
Nov 20, 2017, 12:16:27 PM11/20/17
to
On 18/11/2017 22:03, J. van den hoff wrote:
> the resulting display has the wrong gamma correction

Quite possibly so; we don't apply any gamma correction rules when
reading a PNG. Nor do I know what we ought to do; it currently feels
like one of these things that ought to be obvious but isn't.

Patches to fix this are invited. ;-)

Paul Obermeier

unread,
Nov 20, 2017, 3:12:55 PM11/20/17
to
The PNG gamma problem should have been fixed with revision 404 in May
2016. Please try current Img version, which is 1.4.6.
Binaries for Mac are available on the SourceForge site.

If the display problem does not disappear, please add an example image
to your bug report.

Regards,
Paul

J. van den hoff

unread,
Nov 23, 2017, 6:57:53 AM11/23/17
to
On Monday, 20 November 2017 18:16:27 UTC+1, Donal K. Fellows wrote:
> On 18/11/2017 22:03, J. van den hoff wrote:
> > the resulting display has the wrong gamma correction
>
> Quite possibly so; we don't apply any gamma correction rules when
> reading a PNG. Nor do I know what we ought to do; it currently feels
> like one of these things that ought to be obvious but isn't.

sorry for possibly being unclear: the gamma problem is *not* present with the Tk internal PNG implementation but rather with img::png.

>
> Patches to fix this are invited. ;-)

fortunately (for Tk and for me). I need not to try this ;-).

joerg

J. van den hoff

unread,
Nov 23, 2017, 7:05:38 AM11/23/17
to
On Monday, 20 November 2017 21:12:55 UTC+1, Paul Obermeier wrote:
> The PNG gamma problem should have been fixed with revision 404 in May
> 2016. Please try current Img version, which is 1.4.6.
> Binaries for Mac are available on the SourceForge site.

thanks for the "heads up". I was not aware of this fix....

>
> If the display problem does not disappear, please add an example image
> to your bug report.

I can confirm that the problem is solved in 1.4.6. thank you...

OTOH:

* in the Teapot packaging system the distributed version still is 1.4.4 (that was the one I was using on the Mac)

* in ubuntu, the "libtk-img" package is at an even older version (1.4.2)

question: are there "deep" reasons for this or is it simply that no one in charge has come around to bumping the version to 1.4.6 there? or is 1.4.6 still not considered "stable" or whatever?

thank you,
joerg

MartinLemburg@Siemens-PLM

unread,
Nov 24, 2017, 7:24:12 AM11/24/17
to
Am Sonntag, 19. November 2017 17:35:02 UTC+1 schrieb Luis Alejandro Muzzachiodi:
> It seems that this chunk has been introduced by Apple without documentation. Isn't in the png specification and also, according to some comments(*), is violating the name conventions for publics chunks.
>
> (*)https://stackoverflow.com/questions/33894790/what-is-the-idot-chunk

Ok, violating rules, not documented, not standardized.

So - why not ignoring?

Since PNG files can come from sources, that are out of control, irrelevant information should not lead to "invalid"/unreadable files, all other relevant information is existing and correct!

Why not making the PNG implementation more tolerant?

fsvog...@free.fr

unread,
Nov 24, 2017, 11:49:47 AM11/24/17
to
It's a bug. And it's fixed.

https://core.tcl.tk/tk/info/1c659ef0f1

Francois

Paul Obermeier

unread,
Nov 25, 2017, 8:55:03 AM11/25/17
to
Am 23.11.2017 um 13:05 schrieb J. van den hoff:
> On Monday, 20 November 2017 21:12:55 UTC+1, Paul Obermeier wrote:
>> The PNG gamma problem should have been fixed with revision 404 in May
>> 2016. Please try current Img version, which is 1.4.6.
>> Binaries for Mac are available on the SourceForge site.
>
> thanks for the "heads up". I was not aware of this fix....
>
>>
>> If the display problem does not disappear, please add an example image
>> to your bug report.
>
> I can confirm that the problem is solved in 1.4.6. thank you...
>
> OTOH:
>
> * in the Teapot packaging system the distributed version still is 1.4.4 (that was the one I was using on the Mac)
>
> * in ubuntu, the "libtk-img" package is at an even older version (1.4.2)
>
> question: are there "deep" reasons for this or is it simply that no one in charge has come around to bumping the version to 1.4.6 there? or is 1.4.6 still not considered "stable" or whatever?
>

Well, that's the responsibility of the distribution maintainers.

The Img extension is quite stable. Patches typically include updates of
the 3rd party libraries (zlib, png, tiff) to their latest versions or
bug fixes like the PNG gamma fix.

Regards,
Paul
0 new messages