IPTC/EXIF metadata get lost when resizing images in Contao
markusmilkereit opened this issue · comments
We're having a legal issue right now, that boils down to:
- when using stock images (istock, adobe stock, fotolia etc.) the source file contains copyright information
- when resizing the image in Contao, the copyright information gets lost
- removing copyright information from images is problematic, not to say: illegal
I did a good deal of investigation there, but still have not figured out what specifically Imagine is doing differently. Because Imagemagick and Graphicsmagick have native support for the IPTC and EXIF metadata and retain the data with no extra settings. Console tools behave the same as both PHP extensions. GD does not know how to handle metadata, but it's limited in many other ways too - that's where IM or GM come into play.
But channeling the process through Imagine is doing something to explicitly remove metadata :(
I found a couple of tickets there, but they've been closed for many years due to inactivity.
How could this be solved?
The image handling in Contao is a real USP, fixing the legal issue would be a mandatory step for me to keep it that way :)
the ticket I was referencing above: php-imagine/Imagine#22
I blamed Imagine, and the culprit actually is Resizer->executeResize(). Performing a "strip" at the end of the resize-chain actually removes the meta data, EXIF, IPTC and copyright gone :/
$imagineImage
->resize($coordinates->getSize())
->crop($coordinates->getCropStart(), $coordinates->getCropSize())
->usePalette(new RGB())
->strip() // important part here
;Does it serve a higher purpose? If not I would feature-request that to be a switchable setting, or bugfix-request it to be disabled. The slightly smaller file size is nice, but as written above: also produces illegal files (when copyright information is included).
Do you somehow extract the data and display it on your site? Or is this just for someone who would download and inspect an image?
Just out of curiosity: If removing the metadata is a problem with your images, isn't resizing/cropping/altering as well?
It's coming from the copyright holder downloading the image and checking for his copyright notice.
Other changes to images are allowed, all ok with the image license terms & conditions. But this paragraph (example from Adobe Stock) is pretty clear about the handling of copyright information:
7.1 (H)
[You must not] remove, obscure or alter any propriatary notices associated with the Stock Assets, or give any express or implied misrepresentation that you or another third party are the creator or holder of Intellectual Property Rights in any Stock Assets
Even without those custom business conditions we can't just remove a copyright notice. Local law like the German Urheberrecht provides almost the same rules:
Der Urheber hat das Recht auf Anerkennung seiner Urheberschaft am Werk. Er kann bestimmen, ob das Werk mit einer Urheberbezeichnung zu versehen und welche Bezeichnung zu verwenden ist.
I know it's still somewhat common practice on the web, but many image services already changed to keep the copyright alive (for example cloudimage.io). With a configurable setting, even off by default, we're not losing anything. And if needed you enable it and everyone is happy ;)
[You must not] remove, obscure or alter any propriatary notices associated with the Stock Asset
honestly i dont think "associated" means the same as "embedded" and stripping all the metadata is something i consider a must-have feature not just because of the decrease in filesize but also for privacy reasons.
You probably would not want to leak any device-, time- or geo-information of photos taken by either the owner/editor of the website nor users of the website (user-generated content)
I understand the privacy remark for self-made photos, that's why it should be a dynamic setting. For the whole website, or per image. For copyrighted material the EXIF/IPTC data is something the creator left in the picture, there is no privacy issue involved, it's all public anyway. An "all or nothing" approach would be good enough for the use case described above.
The legal terminology is really not clear enough, I have a meeting with the legal department from Adobe tomorrow to ask directly at the source :)
For the whole website, or per image.
I think the best place to put that option would be in the image-size settings then.
I highly doubt that removing the metadata from the image is a legal problem for stock photos. I would imagine that it could potentially even create legal problems, e.g. if you crop an image and state that the author of this image is the same as in the original photo.
iStock explicitly allows removing the copyright: “You do not need to include a photo credit for commercial use…”
If we want to add this option, wouldn’t it make sense to keep only the “copyright” fields and remove everything else? Like IPTC By-line, By-line Title and Copyright Notice and EXIF Artist and Copyright?
There is also Credit and Credit Line as well as Copyright String - but yeah, I would be fully on board with the option being "keep copyright", not "keep all metadata". The latter is just much easier to do, because that's the native behaviour of IM and GM anyway. In the case of explicitly adding copyright data only it could even be added for GD with https://www.php.net/manual/en/function.iptcembed.php for a more unified approach (on jpgs).
Not included anywhere: how to handle WebP metadata properly, because it does not have IPTC support. There is EXIF and XMP support included however.
I'll be back with hoefully useful updates from the Adobe legal team soon. Because @ausi I'm also convinced that the legal side of the Adobe rules is contradicting a lot of practical and logical use cases.
Small update: I'm still in with the Adobe support, even contact with the legal system takes multiple steps to get a useful answer :/
A lot more information after talking to a couple of copyright lawyers and the legal department for Adobe in Germany.
- for German users keeping the copyright is not necessary, and the matching rule in the Adobe terms does not apply
- for international users it would be important to keep the copyright information in the picture
- optional, but highly recommended in both cases: a complete image overview (with minified versions of the original, and the page it's used on), along with the copyright holder and the creator (Urheber). I rarely see those, but this is a good example (from a Contao page) https://www.academyofsports.de/de/bildnachweise/
To handle 2) this ticket could be a feature request to add "keeping the copyright" as discussed above. We're currently working on a solution for 3) as a Contao extension.
We're currently working on a solution for 3) as a Contao extension.
There already is a simple one: https://github.com/Tastaturberuf/contao-image-copyright-bundle
Though I suspect you also want to display the automatically extracted meta data from the images.
Here is a important addition to this topic:
customer has a legal dispute because of missing EXIF-Data in an Adobe-Stock-Image. Process is still running but if the warning is successful, all images without Copyright or even all EXIF-Data of the image are not legal
What I don’t understand about this requirement:
- If I create a collage with stock photos, do I need to “merge” the EXIF data then?
- Using such images in a video or a screenshot?
- What if I convert the image to a format that doesn’t support EXIF?
- What are the legally allowed EXIF storage options per image format? When converting to PNG, do I have to use an
eXIfchunk (which only exists since 2017 and is not supported by most software) or should I store the data in an arbitraryzTXtchunk named"Raw profile type APP1"or something completely different? - Are all Adobe-Stock-Images using the EXIF standard or would I have to support XMP too?
Sorry, regarding the case of my customer the matter are EXIF-Data.
Basically the point is, the original Meta-Data of an (stock-)image has to be kept.
However, it isn't clear yet if this also means every meta-data stored in the image-file or just the copyright.
Like I said, the dispute is still running.
I just wanted to stress out, if the accuser wins this dispute, it is urgent to have a possibility to keep at least the copyright in the file or it is technically illegal
legal dispute because of missing EXIF-Data
Honestly that would make me move away from this platform.
If you use a Stock-photo for a print-product you will not have the EXIF either.
If you put a photo with such restrictive licensing on a website then just do not process it at all - use it as is - clip and adjust the dimensions with css if needed.
technically speaking the browser can't display "original" EXIF information anyway
just like a flyer can't.
'' rant off
I know that's not very helpful and hope nobody takes this personal.
I just wanted to stress out, if the accuser wins this dispute, it is urgent to have a possibility to keep at least the copyright in the file or it is technically illegal
Note, that this might just be impossible to do from a technical standpoint. See (basically all of) @ausi's questions.
@fritzmg I'm sorry, I just can't answer the questions and I also don't know if it's technically possible...
I'm just a FE-Dev, usually not this deep into the technics... I just don't know what to do besides to ask if it's possible...
I'm also telling my boss and customer it is not possible and indeed not even needed according to @markusmilkereit and most possibly not even going through...
Honestly I also don't understand anyone downloading images, controlling if the metas are there and just accuse around for them not to be...
I'm also not helpful, I know, I'm just a little bit desperate at the moment...
Thank you all for your help and understatement though
@fritzmg I'm sorry, I just can't answer the questions and I also don't know if it's technically possible...
These are questions that you need to forward to the stock image provider. They need to answer how their licensing requirements are supposed to work.
I know that's not very helpful and hope nobody takes this personal.
I think we are probably all on the same page here.
Do we like what Adobe does here? No! UPDATE 2021-06-15: looks like Adobe might be not at fault here.
Do we want to make it possible for Contao users to comply with such rules? Yes, if technically possible without a huge amount of work.
To handle 2) this ticket could be a feature request to add "keeping the copyright" as discussed above.
To me it looks like the “keeping the copyright” feature would be the best fit for the issues from this discussion.
To make that feature possible we would need a definitive list of metadata tags from IPTC, EXIF and XMP that have to be kept in the image file. As this issue seems to be most prominent with Adobe Stock, an official list from Adobe would be best I think. (Otherwise we could miss a tag and make the experience for our users even worse).
We're currently working on a solution for 3) as a Contao extension.
There already is a simple one: https://github.com/Tastaturberuf/contao-image-copyright-bundle
Though I suspect you also want to display the automatically extracted meta data from the images.
Yes, but still very helpful for a first draft - thanks for the hint :) @fritzmg
The whole discussion is not coming from Adobe - who would (based on the Adobe lawyers I talked to) never go against their customers if it's not blatant misuse. It usually is coming from the creators, who are looking for additional income. Based on Adobes feedback those creators are breaking Adobes terms, and Adobe is handling it.
That's why there is no list of EXIF data from Adobe, but there is also no answer from them how to do for example WebP correctly. Which only has XMP support, and no other metadata. And XMP is not widely used (regarding @ausi s questions). They're answer to me was: Adobe will never go after their customers for that, because you're not doing it in bad faith, or to game the system. The images are still being used as they should be. Not very dependable info, but at least from an official source.
customer has a legal dispute because of missing EXIF-Data in an Adobe-Stock-Image.
@FlorinvV is the legal dispute between your customer and Adobe?
@ausi No, between the customer and the creator of the image. The image itself is from adobe stock though.
@FlorinvV did you notify Adobe about this yet? See #80 (comment)
@fritzmg not quite yet, but I try to get it done
In addition to this: my boss is convinced, adobe is not responsible in any case within this dispute, is this true?
As far as i understand the service (adobe) gives license on behalf of the creator to the enduser (your customer).
I doubt that
a) the creator can make up their own quirky licensing terms
b) the service would unveil information about the enduser to the creator
If i was the customer i would stick to the terms of the service and nothing else.
The whole thing seems pretty "scammy" to me.
The whole thing seems pretty "scammy" to me.
It is, that's why Adobe said they are taking legal actions against the creator. They sometimes try, and it sometimes works - I hope this time it properly backfires. But the creator is definitely trying to scam, and breaking Adobes terms while doing it.
Keeping the copyright information alive is still a valuable addition, for a multitude of reasons. Just not the one I started this thread with ;)
I looked a little bit into the different standards (IPTC-IIM, IPTC-XMP and EXIF) and the following fields seem to be used for storing information that might be related to the copyright:
| Name | IPTC | XMP | EXIF |
|---|---|---|---|
| Copyright Notice | 2:116 (128 bytes) |
dc:rights | 8298 |
| Creator | 2:80 (32 bytes) |
dc:creator | 013B |
| Credit Line | 2:110 (32 bytes) |
photoshop:Credit | maybe 9286 (UserComment) |
| Web Statement of Rights (URL) | - | xmpRights:WebStatement | - |
| Creator’s jobtitle | 2:85 (32 bytes) |
photoshop:AuthorsPosition | - |
| Source | 2:115 (32 bytes) |
photoshop:Source | - |
| Rights Usage Terms | - | xmpRights:UsageTerms | - |
| Copyright Owner (with subfields) | - | plus:CopyrightOwner | - |
| Licensor (with subfields) | - | plus:Licensor | - |
| Image Creator (with subfields) | - | plus:ImageCreator | - |
So if we implement this feature, these are the fields we should keep (and/or convert) I think.
Some additional information: https://community.contao.org/de/showthread.php?81070-Urspr%C3%BCngliche-Metadaten-werden-im-Sourceset-entfernt&p=546229&viewfull=1#post546229
Ich klinke mich auch mal ein, da ein Kunde von uns ebenfalls eine Abmahnung bekommen hat:
Ein Fotograf (RC), der bei Adobe Stock verkauft hat und dann seitens Adobe aufgrund Verstöße "rausgeschmissen" wurde, hat nun seine eigene Bilddatenbank aufgebaut und versucht mittels Druckmethoden nun Geld einzutreiben und droht zu verklagen bzw. schaltet auch eine Anwaltskanzlei ein (Spirit).
Es wird abgemahnt, dass die IPTC Daten in der Datei nicht vorhanden sind. Wir haben für den Kunden natürlich auch die Bildoptimierung aktiviert - allerdings fehlen die Meta Daten in den generierten Thumbs.
Grundsätzlich schreibt Adobe mittlerweile in seinem FAQ:Muss ich einen Bildnachweis hinzufügen?
Es muss nur dann ein Bildnachweis hinzugefügt werden, wenn das Bild in einem redaktionellen Beitrag verwendet wird. Wenn Sie Editorial-Bilder in Druck-Erzeugnissen, Websites, Blogs usw. verwenden, muss die auf der Adobe Stock-Website und im IPTC-Feld für die Quellenangabe angegebene Quellenangabe enthalten sein. Beispiel: „Agenturname/Autorenname – stock.adobe.com“.
Quelle: https://helpx.adobe.com/de/stock/help/usage-licensing.htmlEs gibt auch deutliche Hinweise von Adobe, dass sich Betroffene an die entsprechende Kanzlei von Adobe wenden sollen (zur Info für andere Betroffene):
https://community.adobe.com/t5/stock/abmahnung-eines-urhebers-trotz-korrekt-lizensiertes-bildmaterials/m-p/11872677#M57707Es ist meiner Meinung nach sehr wichtig, dass auch die generierten, optimierten Bilder die Daten enthalten. Es ist sicherlich aktuell noch eine Grauzone, jedoch kann schnell mal ein Urteil gefällt werden und dann geht die Abmahnmaschinerie los...
The Adobe lawyers sent an update to the case: they successfully fought off the claims. The photographer was misusing the Adobe terms, and ignored his own terms as content provider in the process. If further legal issues are coming up Adobe actively offered help to fight those off too - apparently they care about protecting their clients. And of course their business model ;)
As written above: keeping the copyright information alive is still a very good idea, not just for Adobe, also for licenses bought from copyright holders directly.
Anwaltskanzlei (Spirit) - Handelt es sich dabei um Spirit Legal aus Leipzig? Dann hätte wir über Nicky Hoff doch guten Kontakt um zu erfragen welche Daten alle übernommen werden sollen bzw. müssen. Gibt ja auch noch ein paar Daten (IPTC-Extension), die sich mit Modellfreigaben befassen (Bereich Peoplefotografie)
Ich muss das Thema noch mal in den Fokus rücken.
Ich habe jetzt auch eine Kundin mit Adobe-Stockfotos. Nach etwas Lesen und recherchieren lese ich jetzt folgendes bei Adobe:
"Es muss nur dann ein Bildnachweis hinzugefügt werden, wenn das Bild in einem redaktionellen Beitrag verwendet wird. Wenn Sie Editorial-Bilder in Druck-Erzeugnissen, Websites, Blogs usw. verwenden, muss die auf der Adobe Stock-Website und im IPTC-Feld für die Quellenangabe angegebene Quellenangabe enthalten sein. Beispiel: „Agenturname/Autorenname – stock.adobe.com“.
Das heißt für mich das IPTC-Feld Quellenangabe darf definitiv nicht entfernt werden, wenn die Bilder von Contao verarbeitet werden..
… muss die auf der Adobe Stock-Website und im IPTC-Feld für die Quellenangabe angegebene Quellenangabe enthalten sein.
So wie ich das lese, müssen diese beiden Quellenangaben als Bildnachweis-Text (vermutlich sichtbar für Website-Besucher) beim Bild angezeigt werden.
Ob beschnittene/optimierte Bilder in den eigenen Metadaten noch etwas enthalten müssen, kann ich aus diesem Textauschnitt nicht herauslesen. Und die Adobe-Anwälte aus diesem Thread haben auch zu keiner Zeit so etwas gefordert.
Zudem gäbe es dann zig technische Fragen:
- Was genau ist das genannte „IPTC-Feld“?
Siehe #80 (comment) es gibt sehr viele verschiedene Felder. - Welcher Standard muss benutzt werden, IPTC-IIM oder IPTC-XMP?
- Wie sind Bildformate zu handhaben welche kein IPTC unterstützen (aber eventuell z. B. EXIF)
Also ich bin nach wie vor dafür, das wir soetwas einbauen.
Aber eine klare Anforderungsliste (zumindest welche Felder, Metadaten-Standards, Bildformate) wäre schon sehr hilfreich. Ansonsten ist die Umsetzung einfach ein Ratespiel 😕
Nein sichtbar auf der Website ist sicher nicht gemeint. Die IPTC-Daten sind genauso wie die EXIF-Daten Metadaten, die mit dem Bild mitgeliefert werden und auch nach dem Download eines Bilder vorhanden und auslesbar sind bzw. ist ggf. beides erforderlich.
Was den Thread mit den Anwälten betrifft - ich bin mir nicht sicher, aber der Hinweis zu den IPTC-Daten ist glaube ich erst neu in den Hinweisen dazu gekommen.
Mit den Datenfeldern schaue ich mal bis zum Call nach, was ich finden kann. Ich kann Dir zu mindestens raussuchen in welchem Feld die Daten von Adobe stehen, weil ich da gerade Bilder von der Kundin habe mit genau diesen Daten.
Ich denke aus dem englisch Text von Adobe geht es etwas besser hervor:
When editorial images are used in print, websites, blogs, etc. you must include the credit line mentioned on the Adobe Stock website and contained in the IPTC credit line field. For example, “Agency Name/Author Name - stock.adobe.com."
Man muss eine Quellenangabe machen, diese findet man auf Adobe Stock und in den IPTC-Daten.
Man soll sich also die Angabe aus den IPTC-Daten kopieren und für die Quellenangabe nutzen.
Mit den Metadaten in Bild-Dateien die ein Webserver ausliefert hat das (nach meinem Verständnis) nichts zu tun.
Ich vermute der hinweis auf IPTC kommt in diesem Fall daher, weil derjenige der das Bild am Ende verarbeitet vielleicht gar keinen Zugang zum Adobe-Stock Account hat, und aber trozdem wissen muss wo er denn die Quellenangabe hernehmen soll.
Wir empfehlen inzwischen Kunden auf Nummer sicher zu gehen und die Bildquellen separat zu dokumentieren. Damit sind auch alle Fälle abgedeckt in denen Ausschnitte von Bildern, Collagen mit Bildern etc. verwendet werden. Fritz hatte oben eine sehr coole, kleine Erweiterung dafür verlinkt (https://github.com/Tastaturberuf/contao-image-copyright-bundle) - nichts gegen ein ausführliches Metadaten-Handling, aber das Thema kann schnell explodieren :)
Wobei auch eine Option möglich wäre: einfach die Metadaten nicht wegwerfen. Hatte ich oben mal dokumentiert - Contao hat einen Aufruf in der Bildbearbeitungs-Logik, die alle Metadaten löscht. Macht die resultierenden Dateien massiv kleiner, und löscht eben auch alle Copyright-Hinweise. Step 1 könnte sein diesen Schritt in den Settings abzuschalten.
Ein Lösungsansatz könnte sein die EXIF Daten im DBAFS zu persistieren und dann ein Content Element zu bauen, das diese dann ausgibt, ggf. gefiltert durch eine Datei/Ordner-Auswahl + die schema.org Einträge aus dem Suchindex.
Aber vermutlich wird das - weil rechtlicher Natur - immer ein manueller Task bleiben.
Ich denke wir haben hier zwei verschiedene Bereiche:
- Anbringen von Urheberrechtsdaten am Bild oder im Impressum je nach Lizenz - das kann man relativ einfach mit Erweiterung oder ggf. auch mit größerem Aufwand händisch in Contao realisieren.
- Der zweite Bereich um den es mir tatsächlich geht sind die Metadaten im Bild (IPTC/EXIF), die man m.E. nicht weglöschen sollte.
Ich habe versucht mich etwas mit den rechtlichen Grundlagen des zweiten Punktes zu befassen und folgenden Artikel gefunden https://kunst-kulturrecht.de/iptc-daten-als-urheberschutz/, der für mich eindeutig dokumentiert, dass es inzwischen Urteile gibt, die das Entfernen von Metadaten als Urheberrechtsverletzung sehen. Damit haben wir m.E. den Zustand, dass Contao die Metadaten möglicherweise rechtswidrig löscht und uns der Kunde der das nicht wissen kann und muss zur Verantwortung ziehen kann, denn wir wissen es bzw. sollten es wissen.
Wenn es so einfach ist wie @markusmilkereit schreibt und man das Löschen der Metadaten einfach weglassen kann, dann wäre es aus meiner Sicht die optimale Lösung für den Punkt 2.
Damit wären dann die Lieferanten der Bilder (Stockfotoanbieter, Agenturen bzw. Fotografen, ggf. noch derjenige der eine Collage erstellt und eigene Metadaten hinterlegt) in der Pflicht die Daten zu hinterlegen bzw. nicht zuvor zu verändern.
I blamed Imagine, and the culprit actually is
Resizer->executeResize(). Performing a "strip" at the end of the resize-chain actually removes the meta data, EXIF, IPTC and copyright gone :/$imagineImage ->resize($coordinates->getSize()) ->crop($coordinates->getCropStart(), $coordinates->getCropSize()) ->usePalette(new RGB()) ->strip() // important part here ;Does it serve a higher purpose? If not I would feature-request that to be a switchable setting, or bugfix-request it to be disabled. The slightly smaller file size is nice, but as written above: also produces illegal files (when copyright information is included).
Nochmal den Beitrag von oben rausgesucht und nachgeprüft: ja, das war der wichtige Teil :)
Wenn es so einfach ist wie @markusmilkereit schreibt und man das Löschen der Metadaten einfach weglassen kann, dann wäre es aus meiner Sicht die optimale Lösung für den Punkt 2.
Habt ihr getestet, ob das auch mit aktivierten Formatkonvertierungen funktioniert wie z. B. „JPG → WEBP“
Das einfache Weglassen der Löschung von Metadaten ist definitiv keine Lösung. Es gibt zahleiche Gründe, die komplett löschen zu wollen und das sollte m.M. auch das default sein.
Wenn's in der Bildgrößen-Einstellung eine Checkbox "Metadaten erhalten" gibt, lassen sich damit wohl erstmal die rechtlichen Anforderungen bedienen.
Ob man dann nur die Liste an Feldern erhält die mutmaßlich relevant sind oder evtl. alle, sowie die Frage nach der Unterstützung bei den verschiedenen Dateitypen kann ich nicht beantworten.
Ich würd' im Zweifel ehrlich gesagt kein einiges Bit an solchen Fotos verändern.
@ausi ich denke auch dass das optionale "Metadaten erhalten" eine schnelle Lösung ist, um den rechtlichen Anforderungen nach zu kommen, dann eben auch in der Kombination dass WebP nicht aktiviert werden sollte (unter anderem weil der Support für Metadaten noch? sehr eingeschränkt ist).
Eine bessere Lösung, aber eben auch mit ordentlich Handarbeit verbunden ist dann eine komplette Übersicht der Lizensierten Bilder zu haben - in dem Fall kann dann wieder voll auf technisch optimale Lösung gegangen werden -> Metadaten löschen, und zu WebP konvertieren.
Ich denke dass sich mit den grad beschriebenen 2 Lösungen dann für die recht fitzelige Version (nur genau die Copyright-Infos zu erhalten) der Aufwand nicht lohnt. Die Copyright-Infos können über mehrere Felder verteilt sein, verschiedene Standards widersprechen sich hier (bzw. ergänzen sich, was fast schlimmer ist). Nur meine Meinung natürlich, auf der Suche nach einer pragmatischen Lösung ;)
@ausi ich denke auch dass das optionale "Metadaten erhalten" eine schnelle Lösung ist,
Ich vermute, dass die Zeile ->strip() zu entfernen alleine nicht ausreichen würde für dieses Feature. Das müsste noch ausreichend getestet werden (sowohl mit GMagick, Imagick als auch mit GD).
Ich hab ein etwas ungutes Gefühl dabei, eine Einstellung hinzuzufügen die wir „Metadaten erhalten“ nennen, die dann aber nur zu 80% funktioniert. Das könnte finde ich ein falsches „Sicherheitsgefühl“ verursachen und im Endeffekt vielleicht sogar mehr Schaden anrichten 😕
um den rechtlichen Anforderungen nach zu kommen
Wenn mir jemand diese Anforderungen nennen kann (am besten mit Belegen), dann würde ich wohl schon etwas Zeit in eine korrekte und möglichst vollständige Implementierung investieren.
Ich denke dazu müsste man die Urteile lesen und interpretieren. Im deutschen Gesetz (§ 95c Abs. 2 UrhG) steht es ja nur sehr allgemein und wie immer mit Spielraum zu Interpretationen. Vielleicht kann Nicky Hoff mit seinem Kontakt zu Spirit Legal da unterstützen und wir können uns informieren lassen, was tatsächlich nicht gelöscht werden darf.
Wie wäre es im ersten Schritt mal mit einer pragmatischen Lösung? Bei den Kunden bei denen es Ärger gab haben wir manuell das ->strip() deaktiviert und einen Update-Hook geschrieben der das dauerhaft deaktiviert lässt. Nicht gerade die Krone der Schöpfung. Das einmal als einstellbare Option würde akute rechtliche Abhilfe schaffen. Eine gute Lösung lässt sich dann immernoch nachrüsten, wird aber deutlich länger dauern :/
@ausi wir können uns gerne mal abends in einem Chat oder Zoom treffen um die Details durchzusprechen, ich war mehrere Monate mit Adobe, dem Gegenanwalt und zum Schluss Adobes Anwälten in der Diskussion, und hab dazu auch geschaut wie andere CMS bzw. andere Agenturen / Projekte das Problem gelöst haben. Wo wäre geschickt? Mein Mittwoch abend sieht aktuell noch gut aus :)
Perfekt wäre am Donnerstag um 15:00 Uhr, da ist der nächste öffentliche Slack-Call: https://contao.org/de/veranstaltungen.html
Dort könnten wir grob diskutieren wie wir das handhaben möchten (aber vermutlich nicht länger als 15min), dort wäre dein Input Gold wert 👍
Wenn es dann noch details zu klären gibt gerne im anschluss an den öffentlichen Call irgenwo im Slack
As discussed in the Contao call today, we want to make it configurable which metadata fields we want to keep.
This has to work for all imagine drivers (GD, IMagick, GMagick). And for all image formats that support metadata.
Gibt es hier eigentlich irgendwelche Neuigkeiten?
Eventuell wäre es ja eine Variante, dass dieses (leider notwendige Feature) per Sponsoring etwas schneller implementiert werden?
Viele Grüße
I started working on this, see #93
Eventuell wäre es ja eine Variante, dass dieses (leider notwendige Feature) per Sponsoring etwas schneller implementiert werden?
Ja. Für Sponsoring bitte auf Slack ( https://contao.slack.com/archives/C04BA74N6NR/p1669989797140249 ) oder bei martin@contao.org melden, danke!
Der Pull request #93 ist gemergt.
Bitte in euren Installationen mit "contao/image": "1.x-dev", testen (und Bilder-Cache leeren).
Die Copyright-Infos sollten damit in euren Bildern erhalten bleiben.
Nächste Schritte sind dann die Konfigurierbarkeit über Contao und die Integration der gelesenen Daten im Dateimanager.
PS: Sponsoring ist immer noch möglich 😅 martin@contao.org
Hallöchen, ich habe gerade die 1.x-dev installiert und den Bilder-Cache gelöscht. Leider haben die generierten Bilder keine IPTC-Daten.
Zur Sicherheit habe ich das Original aus der Dateiverwaltung überprüft, hier sind die Daten vorhanden. Cache ist auch sicher geleert. contao/image ist im Manager unter Pakete mit Version 1.x-dev aufgelistet.
Hab ich noch etwas vergesssen?
Kannst du mir eines der Bilder zur Verfügung stellen (z. B. via Slack), damit ich es mit diesem Bild testen kann?
Update: Bei mir lag das Problem vermutlich am Cache. Aktuelle Tests zeigen, alle relevanten IPTC-Daten sind vorhanden. 🥳
Nächste Schritte sind dann die Konfigurierbarkeit über Contao und die Integration der gelesenen Daten im Dateimanager.
Version 1.2.0 wird in den nächsten Tagen released werden. Letzte chance für feedback
Ich habe heute auch noch einmal getestet.
Allerdings in Contao 4.13.
Schade, dass das Feature nicht in Contao 4.13 implementiert wird, wenn ich es richtig verstanden habe.
Sowohl mit Umwandlung in webp als auch ohne waren die eingetragenen relevanten IPTC-Daten vorhanden.
Schade, dass das Feature nicht in Contao 4.13 implementiert wird, wenn ich es richtig verstanden habe.
Es wird auch in Contao 4.13 implementiert werden (sodass die Copyright-Infos in den Bildern erhalten bleiben). Allerdings wird es erst ab Contao 5.2 die Möglichkeit geben dies detailliert über die Bildgrößen einzustellen. In Contao 4.13 muss man sich also mit der Standardeinstellung zufrieden geben, was aber für die meisten Anwendungsfälle passen sollte denke ich.
Version 1.2.0 von contao/image wurde soeben veröffentlicht.
Nach einem Update und dem leeren des Bilder-Cache sollten nun die Copyright-Metadaten in euren Bildern erhalten bleiben 🎉