Possibly fixed in PHP 7.4 support ??
https://github.com/php/php-src/commit/fbb169019842996db693e021c46dac9b68698f15

ah no, that's already in 7.2 which i'm also running

It's actually the opposite.. HHVM never had https://github.com/php/php-src/commit/fbb169019842996db693e021c46dac9b68698f15 which was a very late php5.6 change and added support for the Panasonic MakerNote format. Because of the support, it hits more than 150 exif key/value pairs in php7 which is the limit, even though in hhvm the limit with just 100 (without Panasonic MakerNote support) we didn't hit it.

So do I understand correctly that we're actually hitting a hard-coded limit in PHP which cannot easily be changed? I guess patching PHP to set the limit to 200 or 250 is not an option, right? Is there anything we can do about this at all?

@Reinhard_Mueller correct. We can file a ticket upstream with PHP (and we probably should), but it will take a long time to fix.

Maybe we can do a wikimedia patch...

Some possibly related tickets:
https://bugs.php.net/bug.php?id=75785
https://bugs.php.net/bug.php?id=78083
https://bugs.php.net/bug.php?id=78701

I compiled my own php and have been able to confirm that we are indeed running into the maximum number of exif tags. This is less visible than ud think, because unknown tags get skipped in the parser results, but are counted when doing the actual parsing. Will see if the limit can be safely raised.

I recently bought a NIKON CORPORATION: COOLPIX P1000. It works with version ID: 2.3.0.0. Just like my Panasonic: DMC-TZ61. Amazing for me: the UploadWizard processes the images of the NIKON CORPORATION: COOLPIX P1000 without any problems: see:

https://commons.wikimedia.org/wiki/File:20200806_xl_0033-solarpark-an-der-b1-bei-Ruedersdorf-ortsteil-tasdorf.jpg

but still no pictures of the Panasonic: DMC-TZ61:

https://commons.wikimedia.org/wiki/File:20170910_xl_P1150222-windkraftanlagen--wka--im-windpark--werder-zinndorf--rehfelde-amt-maerkische-schweiz.jpg

In T240509#5764274, @TheDJ wrote:

Some possibly related tickets

• https://bugs.php.net/bug.php?id=75785 seems fixed in 7.3 (attempt switching endianness when extracting Maker Notes IFD tags)
• https://bugs.php.net/bug.php?id=78083 seems not reproducible in 7.3: no more "maximum directory nesting level" warning
• https://bugs.php.net/bug.php?id=78701 is still open and last comment mentions 7.4.3
• https://bugs.php.net/bug.php?id=75424 is still open in 7.3.3

• https://bugs.php.net/bug.php?id=78701 supposed to be fixed as of PHP 7.3.23 and 7.4.11

@TheDJ: I was very happy to see that now the "Location" is read again by the Upload Wizzard. But it still does not work:

• see here: https://commons.wikimedia.org/wiki/File:20171001_xl_P1160009-Windkraftanalgen-vom-Hermannsdenkmal-aus-gesehen.jpg
• added by hand: https://commons.wikimedia.org/wiki/File:20171001_xl_P1160018-Windkraftanalgen-vom-Hermannsdenkmal-aus-gesehen.jpg

very unfortunate
many greetings
Molgreen

@Molgreen Its fixed in PHP, but not in the version of PHP that the WMF currently runs.

@TheDJ Thank you for the feedback. Is there anything I can do to somehow speed up the implementation by WMF?

There is not much to "implement" here but updated PHP packages to ship in the Debian Linux distribution, as WMF servers run on Debian. (Basically.)

@Aklapper How do WMF administrators find out about the new version? (Is there a communication channel?)

I'm not sure what "WMF administrators" are, sorry. The operating system/distribution on WMF servers receives new updates via updating or upgrading.

@Aklapper okay, thank you very much for the feedback. Can you tell approximately when the update could be effective.

I don't know Debian's update policies, sorry.

@Aklapper thank you, not so bad. The thing interests me because I think the location data is very important.
@Krinkle Thanks also to you

Just to let you know, this now seems to work again.

Thank you very much! I just tested it and it works: https://commons.wikimedia.org/wiki/File:20171002_xl_P1160156_Windkraftanlage_bei_Bad_Salzuflen.jpg