Where AI-Generated Labels and Marks Disappear in Images and 3D Data — 2,862 Article Images Counted Before the December 2 Deadline

When you attach AI-generated labels to images you made with AI, the sentence a person reads and the “mark” a machine reads turn out to be two different things. The label people see goes in the article body or the caption; the mark machines read goes inside the image file. Under the EU AI Act, too, separate provisions apply to each. And for the machine-readable mark, a deadline arrives on December 2, 2026.

This article contains affiliate links. As an Amazon Associate, we earn from qualifying purchases.

The article images on this site are generated with ComfyUI on a local PC. ComfyUI writes the settings used for generation into the PNG as a “generation record.” This record is not a standard mark indicating AI generation. It is still useful material for finding out where, on the way to publication, information written inside a file gets lost. So we counted at which stage the record disappears, using the 2,862 PNGs in our local article folders and images re-downloaded from the public WordPress URLs.

Here are the results first. Locally, 2,816 of the 2,862 images carried the generation record. Among the PNGs re-downloaded from the public URLs, however, 29 full-size originals and 203 resized images, the number carrying the record was 0. To isolate the cause, we uploaded a test image: right after upload, the full-size original still had the record. In a read 17 minutes after upload, the full-size file had been replaced by a smaller file with identical pixels, and the record was gone.

This article summarizes the text of the regulation and the European Commission’s explanations; it is not legal advice. It does not judge whether readers or this site bear any obligation under the provisions. We measured only cases where information is lost unintentionally in everyday work, such as resizing or re-saving; methods for removing marks are not covered. Each experiment was run once per condition, and the results are reported as “this is what happened in this run.”

Only the Article 50(2) transitional period ends on December 2

Article 50 of the AI Act (Regulation (EU) 2024/1689) sets transparency obligations for providers and deployers of certain AI systems, and it started to apply on August 2, 2026. The timeline on the European Commission’s AI Act Service Desk says in its entry for that date: “Transparency rules (Article 50) start to apply.”

December 2 is a deadline that applies to paragraph 2 alone. It concerns providers of AI systems, including general-purpose AI systems, that generate synthetic audio, image, video or text content and that were placed on the market before August 2, 2026. December 2 is the end of the transitional period for those providers to comply with Article 50(2) (machine-readable marking and detection).

The legal basis is Article 111(4) of the AI Act. This paragraph was added by Article 1, point 39(b), of Regulation 2026/1744 (the Digital Omnibus on AI), published in the Official Journal on July 24, 2026. Recital (38) of the same regulation explains that a transitional period of four months is appropriate for providers that are already on the market.

The Commission’s Q&A also says that the grace period is limited to AI systems placed on the market before August 2 and is granted only for the marking and detection obligations of paragraph 2. Readings such as “Article 50 applies from December 2” or “all of Article 50 has been postponed” therefore do not match the text. Note that some prohibitions (on AI systems that generate content such as non-consensual sexual deepfakes) also start to apply on the same December 2.

We sorted out the dates and framework of the AI Act and the Omnibus from primary sources in Update the Law Before You Memorise It: Japan AI Act, Copyright, and the EU AI Act (published 2026-10-04), and this article does not repeat that. From here on, we focus on how the “machine-readable mark” required by paragraph 2 is handled inside files.

Machine-read marks and human-read AI-generated labels

The original text of Article 50(2) requires providers to ensure that the outputs of their AI systems are “marked in a machine-readable format and detectable as artificially generated or manipulated.” The condition is not whether a person can tell by looking. It is whether a mark is attached in a machine-readable form and the content can be detected as artificially generated or manipulated.

Article 50(4), by contrast, requires deployers of AI systems that generate or manipulate image, audio or video content constituting a deepfake to disclose that the content has been artificially generated or manipulated. Article 3(60) defines a deepfake as AI-generated or manipulated image, audio or video content that resembles existing persons, objects, places, entities or events and would falsely appear to a person to be authentic. The same paragraph also requires deployers of AI systems that generate or manipulate text published with the purpose of informing the public on matters of public interest to disclose, with some exceptions, that the text has been artificially generated or manipulated.

In this article, what machines read under paragraph 2 is called a “mark,” and what people can see, such as the paragraph 4 disclosure, is called a “label.” AI-generated labels and marks are never used interchangeably here. In the text of the regulation, the split is that providers apply marks and deployers disclose. This article does not, however, judge which of the two a reader is.

Recital (133) of the AI Act lists examples of marking techniques: watermarks, metadata identifications, cryptographic methods for proving the provenance and authenticity of content, logging methods, fingerprints and so on. Of these, the two that image creators handle on their own machines are metadata written into the file and digital watermarks embedded in the pixels.

Marks written into the file: C2PA, XMP and PNG text

The first approach is metadata written inside the image file. A representative example is the specification of C2PA (Coalition for Content Provenance and Authenticity), which places a “manifest” recording provenance into the file together with a digital signature. For PNG, version 2.5 of the specification puts the manifest in a chunk of type caBX. This chunk is defined as ancillary, private and “unsafe to copy.”

That “unsafe to copy” has consequences. The PNG specification (the W3C Recommendation, Third Edition) states that when a PNG editor modifies critical chunks of an image, it must not copy unknown unsafe-to-copy chunks to the output. In other words, an editor that changes critical chunks is required not to carry caBX over to the new file if it does not recognize caBX.

Separately from C2PA, AI generation can also be indicated with an XMP field. IPTC Photo Metadata defines a field called Iptc4xmpExt:DigitalSourceType, and for images created with generative AI it uses the value trainedAlgorithmicMedia (named “Created using Generative AI”). Inside a PNG, XMP goes into an iTXt chunk with the reserved keyword “XML:com.adobe.xmp,” and EXIF goes into an eXIf chunk.

PNG also has text chunks, tEXt, zTXt and iTXt, that hold keyword and string pairs. The generation record that ComfyUI writes goes here. It is, however, the settings of the nodes used for generation serialized as JSON, not a standard value meaning “AI-generated” like C2PA or DigitalSourceType. For that reason, this article does not call it an “AI-generation mark” but a “generation record.”

Marks embedded in the pixels: digital watermarks

The second approach is a digital watermark, which embeds an imperceptible signal in the pixels themselves. Metadata is written in a part of the file separate from the pixels, whereas a watermark goes into the pixels. That is the major difference between the two.

The code of practice discussed below positions watermarks as a robust mechanism that complements digitally signed metadata. Which processing a watermark survives depends on the method, and this article did not measure it.

Labels people see: written in the body or the caption

A label is written so that people can see it. It takes forms such as writing “generated with AI” near the image or explaining it in the article body. As an example: the images for this article were generated with ComfyUI and Z-Image-Turbo, and carry neither C2PA nor a watermark.

Now back to the question in the title. AI-generated labels written in the body or a caption live on the page side and do not go inside the image file. A mark, conversely, lives inside the file, so it can be lost at any stage where the file is re-saved or replaced. Labels and marks sit in different places, and they disappear in different places. The measurements in this article deal with where the information inside the file disappears.

The code of practice asks signatory providers for two layers of marks

On June 10, 2026, the European Commission published the final version of the “Code of Practice on Transparency of AI-generated Content.” It was drawn up by independent experts, and adherence is voluntary. The Commission notes, however, that while adherence to the code is voluntary, the transparency requirements of Article 50 themselves are legal obligations.

The text of the code requires signatory providers to apply at least two layers of machine-readable marking to the outputs of generative AI. One is digitally signed metadata; the other is an imperceptible watermark. These two layers are measures for audio, images, video and containerised text, and they rest on the premise that they apply while no single marking technique can meet the requirements of Article 50(2) on its own. In the code, “will” denotes mandatory measures and “encouraged” denotes voluntary measures that are not legally required. The two layers are written with “will.”

For the metadata layer, where the format can carry metadata, the provider records whether the content was generated or manipulated by AI and digitally signs all the recorded information. Systems that can use time information also add a timestamp. The watermark layer is described as a robust mechanism that complements the signed metadata. Fingerprints and logs, on the other hand, are described as optional aids, and relying on them alone is said to be insufficient.

In some cases one layer is considered enough. Free-form text cannot carry metadata, so a single watermark layer suffices. Generative AI systems built into physical products that produce synthetic output in a technically controlled, closed environment may also use a single layer in certain cases. The code further states that compliance may in future be demonstrated with other marking techniques (even a single one) if equal or better performance can be shown to market surveillance authorities.

What matters for the measurements in this article is the measure on preserving marks (Measure 1.2). To the extent technically feasible and recognizable by open standards, signatory providers preserve existing metadata marks present in the input and do not intentionally alter or remove them. This is written with “will.” The same measure also says, however, that it does not prevent legitimate processing in good faith, such as changes or replacements needed to keep the information accurate in later processing. For signatories that operate online platforms or search engines, by contrast, preserving metadata marks on those services is “encouraged,” that is, merely recommended. Measure 1.3, which covers additional provenance information (the name of the AI system, the provider’s company name, the generation time and so on), is also voluntary.

The code itself acknowledges that the standards for metadata marks need further work. On July 8, the Commission concluded that the code adequately covers the obligations of Article 50(2), (4) and (5), and the AI Board adopted its assessment the following day. The Commission also writes, however, that adherence to the code is not conclusive evidence of compliance with the obligations.

One more point to note: the two layers are measures aimed at providers that signed the code, and the law itself does not mandate two layers. The Article 50 guidelines adopted by the Commission on July 20, 2026, say that, as long as the requirements are met, providers may rely on a single marking technique or on a combination of several. They also say there is no obligation to record and preserve the entire chain of provenance.

What the regulation and the guidelines say about 3D data

For 3D printing makers, the natural question is whether AI-made 3D data falls within this discussion. Here two facts must be read side by side.

The first is the text of the regulation. Article 50(2) lists “audio, image, video or text,” and 3D is not mentioned. Paragraph (60) of the guidelines also states that this list of content types covered by paragraph 2 is exhaustive.

The second is paragraph (61) of the guidelines. It states that AI systems generating or manipulating 3-D images, 3-D video and 3-D audio, as well as virtual, augmented and mixed reality, fall within the scope of Article 50(2). It then states that the outputs to be marked are the final form of individual assets, and that point clouds and 3D meshes used to create 3-D images and the like do not need to be marked.

Read together, the two rule out saying “3D is out of scope.” Nor, however, do they settle whether anything is required of data for 3D printing. The guidelines are not binding, and they themselves note in (5) that an authoritative interpretation of the AI Act can ultimately be given only by the Court of Justice of the European Union. This site does not judge whether STL or 3MF files for 3D printing count as the 3D meshes the guidelines refer to.

C2PA’s table of supported formats names no 3D format

From here on, the subject is format specifications rather than the law. Version 2.5 of the C2PA specification (October 2026) lists supported formats in the table in Appendix A.1. Version 2.5 added embedding in append-only text, WARC, Standard MIDI, TTML, ONNX, SafeTensors, Apache Parquet and more. While the supported formats have grown in this way, the Appendix A.1 table does not name 3MF, STL, OBJ, glTF/GLB or USD.

The table does, however, include generic rows such as “Other ZIP-based formats.” The specification does not say whether 3MF and similar formats fall under them. The design explanation says the manifest container can also be used for 3D formats, but it does not define how to embed it in any specific format. So one cannot flatly say “C2PA does not support 3D” either.

On the implementation side, the support table of c2pa-rs, the C2PA SDK (supported-formats.md at commit c13b05f), does not list any 3D format either. The table does not list ZIP-based formats, but the code does have handling for ZIP-based formats such as EPUB and docx. Its list of extensions does not include 3mf.

In short, where to write “AI-generated” in 3D data so that it reaches the next tool is not settled by legal interpretation. It is a question to check against format specifications and the actual behavior of tools.

How this site’s article images flow, from ComfyUI to WordPress

Before the measurements, here are the stages this site’s article images pass through. We generate images with ComfyUI running locally; how that works and how to read the model licenses are covered in Covering Your Article Images Locally — ComfyUI, FLUX, and Reading the Licence Right (published 2026-08-27). Here we read from the repository code what happens to the file at each stage.

ComfyUI’s SaveImage node writes prompt (the JSON of the node settings used for generation) into the PNG’s text chunks unless the launch option --disable-metadata is set. When run from the UI, it also writes the workflow. The workflow is included in the request’s extra_data and passed to SaveImage. This site’s generate.py runs through the API and does not send extra_data, so we expected only prompt to be written into the article images.

Generated images are fetched from ComfyUI’s /view and saved into a local images folder. Unless a preview or similar option is specified, ComfyUI returns the file as is. generate.py simply writes those bytes out, so the record does not change.

generate.py also has a function for overlaying text on an image. It runs only when image_prompts.md has an **Overlay:** line; it opens the image with Pillow, composites, and re-saves it. In addition, deploy.py, the posting tool, normally sends images as their original bytes. Only when the server’s WAF rejects the upload (HTTP 403) does it re-save the image as PNG with Pillow and resend it.

In neither re-save is pnginfo passed to Pillow. Pillow’s code (12.1.0 locally; the latest 13.0.0 is the same) shows that when saving a PNG, text chunks are written only when pnginfo is passed. EXIF, likewise, is written only when exif is passed. An ICC profile, on the other hand, is carried over from the original image even if not passed. Pillow does not strip all metadata; what it writes depends on what you pass. Note that this is behavior read from the code, not wording from the official documentation.

Locally, 2,816 of 2,862 images carried the generation record

First, we counted the local images. The target was every PNG in the images folders of the article folders: 2,862 images from articles dated January through November 2026. We walked the PNG chunks in each image’s bytes and counted the text chunk keys and the presence of EXIF (eXIf), XMP and C2PA (caBX).

“Has a generation record” was defined as having a text chunk with the key prompt whose body parses as JSON. The run was on November 2, 2026, on Windows 11 Pro with Python 3.13.17 and Pillow 12.1.0. The images were only read, never re-saved.

The only text chunk was prompt, and 0 images had a workflow. This matches the expectation read from the code: runs through the API without sending extra_data. EXIF and XMP were also 0, but SaveImage never writes these two in the first place. The correct reading is therefore that they were never there, not that they disappeared.

46 images lacked prompt. Of these, 25 images from articles dated 2026-01-13 to 01-19 carried C2PA, and 21 images from articles dated 2026-01-06 to 01-12 carried no record at all.

We also counted the text overlay settings from each article’s image_prompts.md. With an overlay setting: 0 images; without: 2,825; for 37 images image_prompts.md could not be read, so their status is unknown. Within the settings that could be read, none used the overlay stage that re-saves images.

If you only want to check whether a local PNG has a generation record, you can also open it with Pillow and look at text. According to Pillow’s official documentation, when a PNG is opened, Image.text holds the values of tEXt, zTXt and iTXt as a dictionary. Here is a read-only example (replace the file name with your own image).

from PIL import Image

with Image.open("cover.png") as im:
    print(sorted(im.text))

For a PNG written by ComfyUI’s SaveImage with default settings, prompt appears among the keys. A C2PA manifest, however, goes into caBX rather than a text chunk, so it does not show up this way. The counts in this article were made separately, with a script that walks the chunks directly.

The 25 images from January 2026 carried Google’s C2PA

The 25 images with C2PA predate our use of ComfyUI. Read with c2patool 0.28.4, the manifests of all 25 had been created by the Google C2PA Core Generator Library, and the organization name in the signing certificate was Google LLC. The first action was c2pa.created and the digitalSourceType was trainedAlgorithmicMedia, so creation with generative AI was recorded with standard values. The signing times ranged from 2026-01-10T10:37:17Z to 2026-01-17T09:10:28Z.

c2patool judged all 25 as Invalid. The results showed two issues: the signing certificate was not trusted (signingCredential.untrusted), and it had expired (signingCredential.expired). c2pa-rs 0.91.7, used by c2patool 0.28.4, treats signingCredential.untrusted as a tolerated failure when deciding whether a manifest is Valid. With untrusted alone the verdict would be Valid, so the Invalid verdict came from the expiry. Expiry is c2patool’s verdict and does not mean the images are fake. Of the 2,862 local images, these 25 were the only ones carrying a mark that indicates AI generation with standard values.

Counting PNG chunks across a few thousand files is the kind of job a short Python script handles well. If you want to run similar audits on your own images, a practical Python book that covers file and folder automation is a good place to start.

Automate the Boring Stuff with Python, 3rd Edition

Paperback, 3rd edition (No Starch Press, May 2025) on Amazon.com

Amazon

ポチップ

Images re-downloaded from the public URLs: 0 in full size and resized alike

Next, we examined the images uploaded to WordPress. The targets were the images of five posts; we re-downloaded the full-size images and every resized size WordPress had created. Published images were examined only by reading (GET) from the public URLs, and no post or image was changed.

In the resized file counts, the two WordPress size names (thumbnail and post-thumbnail) that point to the same 150×150 file are counted as one. In the three posts uploaded as PNG, prompt was absent from all 29 full-size images and all 203 resized images. We have local PNGs of the same images, and those carry the record. So we compared the 29 full-size images with the local files.

We compared them in two ways: whether the bytes matched, and whether the pixels converted to RGB matched. All 29 matched in pixels, and none of the 29 matched in bytes. The published full-size images contained only three chunks, IHDR, IDAT and IEND, and not a single text chunk. In other words, the pixels were the same as the local ones, but the files were different.

The images of the two posts from January 2026 (1868 and 1931) were uploaded as JPEG and had no C2PA, EXIF or XMP. The local PNGs carry Google’s C2PA, but because the formats differ, these records cannot tell us at which stage before publication the local marks were lost.

Where did it disappear? Present right after upload, replaced later

The record present locally was gone from the published full-size images. At which stage, then, did it disappear?

This site’s WordPress has the image optimization plugin EWWW Image Optimizer 8.9.1 active. We confirmed this on November 2, 2026, by reading the plugin list through the REST API. EWWW’s descriptions (the readme in the distribution and the official documentation) say that it removes metadata by default, explaining that it strips everything that does not describe how the pixels are drawn. They also say it automatically optimizes images uploaded to the media library and replaces them only when the optimized version is smaller. We did not, however, read this site’s EWWW settings.

To isolate the cause, we uploaded and measured a test image separate from the published posts, and deleted it after measuring. It was based on the cover image (1280×720) of the 2026-11-02 article. We made a PNG containing a generation record (prompt), XMP (DigitalSourceType set to trainedAlgorithmicMedia), a C2PA manifest signed with a test key, and more. Its size was 939,713 bytes.

The upload did not go through deploy.py; we sent the file’s bytes as they were to the REST API. The image was not attached to any post. We then re-downloaded and read the full-size and resized images twice: right after upload (12:23) and 17 minutes later (12:40).

Right after upload, the full-size image had the same byte count as the uploaded file, and prompt, XMP and C2PA were all intact. The resized images lacked C2PA from the start, but the PNG resized images still had prompt. In the read 17 minutes later, however, the full-size image had been replaced: the 939,713-byte file had become an 814,653-byte file. We read only these two times, so the exact time of the replacement is unknown. The RGB pixels matched the right-after file exactly, while C2PA, prompt and XMP were all gone. All text chunks had also disappeared from the PNG resized images.

In a JPEG test image uploaded at the same time, the full-size image was likewise replaced, going from 222,821 bytes to a 157,338-byte file, and C2PA, XMP and EXIF were gone. A WordPress core developer post (4.5, 2016) says that uploaded full-size images are not affected by that version’s changes to image processing. The later replacement of the full-size image is consistent with EWWW’s description.

This result is one explanation for why the published images lack a generation record. With this site’s combination of WordPress core and EWWW Image Optimizer 8.9.1, the test image’s full-size file was replaced after upload by a smaller file with the same pixels, and the record disappeared. The replacement appears to be EWWW’s optimization, but we did not read EWWW’s processing logs and did not confirm this directly.

There is, however, also a path that loses the record before upload. If deploy.py is rejected by the WAF and resends an image, that image already lacks the record at upload time. A resend does not change the pixels, and ending up with only IHDR, IDAT and IEND chunks is equally true of files replaced after upload. So the published files cannot tell us which path an image took, and we kept no record of which images were resent. To sum up: for the test image, the record was lost through replacement after upload (apparently EWWW’s optimization), and the record is also lost by a WAF resend before upload. At which stage past published images lost the record cannot be distinguished; all we can say is that these two paths exist.

What these measurements cannot tell us

No general conclusion can be drawn from these measurements. Here is what they cannot tell us.

• Each condition was run once. The local count, the re-download from the public URLs and the two reads of the test image were each done only once
• The generation stage itself was not measured. We measured files already saved in the local images folders, not files straight out of ComfyUI. The ComfyUI version in use when the article images were generated is also unknown
• Which path each published image took to lose its record is unknown. Whether a deploy.py resend or the later replacement occurred cannot be determined from the files or from any record
• These are results for this site’s setup. We read neither the EWWW settings nor which image editor implementation WordPress uses. On sites with other plugins or settings, the stage where information disappears may differ
• Only uploads through the REST API were measured. Uploads from the block editor were not measured
• Nothing can be said about the January 2026 JPEG posts. Their format differs from the local PNGs
• A generation record is not an AI-generation mark. As the resized images right after upload showed, keeping prompt but lacking C2PA, the stage where information disappears differs by type of information. Results for the generation record cannot be applied directly to C2PA or watermarks
• This is not a legal assessment. This article does not judge who is required to do what

Applying, surviving, placement: three open questions about marks

What these measurements show is one example of where information written into a file disappears along this site’s pipeline. Thinking of it as an AI-generation mark, the question splits into three.

• Applying: When you attach a C2PA manifest to your own image, what does a verification tool show it has checked, and what does it show it has not checked? Can a digital watermark still be read after resizing, JPEG compression and cropping?
• Surviving: Do C2PA and watermarks survive WordPress resizing and image optimization? For 3D printing data, does an “AI-generated” note written into the file survive being loaded into a slicer and saved again?
• Placement: In 3D data such as 3MF, glTF and STL, where should “AI-generated” be written so that it reaches the next tool? For formats not named in the C2PA table, can a manifest placed beside the file be used?

Each of these questions is checked through the behavior of files and tools, not through legal interpretation. And as the measurements above show, something present right after upload can be gone a while later. When checking, the timing of the read must be part of the conditions.

If you plan to test where a mark survives in 3D data yourself, it helps to be comfortable importing and exporting models in Blender first.

Blender for Beginners Part 1

USD 35.99 on Amazon.com (as of 2026/09/22)

Amazon

ポチップ

Summary: check AI-generated labels and marks separately

Here are the key points of this article.

1. December 2, 2026, is the end of the transitional period for providers of AI systems, including general-purpose AI systems, that generate synthetic audio, image, video or text content and were placed on the market before August 2, to comply with Article 50(2) (machine-readable marking and detection). The basis is Article 111(4); Article 50 itself has applied since August 2
2. Machine-read “marks” and human-read “labels” are different things. Marks include metadata written into the file and digital watermarks embedded in the pixels. The code of practice asks signatory providers to apply at least two layers of marks to outputs such as images (one layer can suffice in some cases). The guidelines say a single technique is acceptable if the requirements are met
3. On 3D, the list in the text of Article 50(2) does not mention 3D. The Commission’s guidelines (which are not binding), on the other hand, bring 3-D images, video and audio into scope and say that point clouds and 3D meshes used to create them do not need marks. The table in Appendix A.1 of C2PA 2.5 does not name 3MF, STL, OBJ, glTF/GLB or USD
4. Of this site’s article images, 2,816 of 2,862 local images carried ComfyUI’s generation record, but 0 did among the 29 full-size and 203 resized PNGs re-downloaded from the public URLs. For the test image, the full-size file still had the record right after upload; in a read 17 minutes after upload it had been replaced by a smaller file with the same pixels, and the record was gone. A deploy.py resend before upload also loses the record

To check the same thing in your own image pipeline, read and compare the file before upload with the full-size image fetched from the public URL. When you do, read it again after some time has passed, not only right after upload. On this site, a record that was present right after upload was gone in a later read. The label people see is on the page; the mark machines read is in the file. Writing AI-generated labels in the body and checking whether the mark inside the file survives are best treated as two separate tasks.

Sources

• European Commission AI Act Service Desk, “Timeline for the Implementation of the EU AI Act”
• European Commission AI Act Service Desk, “Article 50”
• European Commission AI Act Service Desk, “Article 111”
• Regulation (EU) 2024/1689 (EUR-Lex)
• Regulation (EU) 2026/1744 (EUR-Lex)
• European Commission, “Questions & answers: Transparency obligations under Article 50 of the AI Act”
• European Commission, “Code of Practice on Transparency of AI-generated Content”
• European Commission, “Code of Practice on Transparency of AI-generated Content,” full text (PDF)
• European Commission, “Commission opinion on the assessment of the Code of Practice on Transparency of AI-generated Content”
• European Commission, “Guidelines on transparency obligations for providers and deployers of AI systems”
• European Commission, Article 50 guidelines, full text (PDF)
• C2PA, “Content Credentials: C2PA Technical Specification” 2.5
• contentauth/c2pa-rs, “supported-formats.md” (commit c13b05f)
• W3C, “Portable Network Graphics (PNG) Specification (Third Edition)”
• IPTC, “Digital Source Type” NewsCodes
• IPTC Photo Metadata Standard 2025.1
• Comfy-Org/ComfyUI, “nodes.py” (commit 17ff1dc)
• Pillow, “Image file formats”
• Pillow 12.1.0, “PngImagePlugin.py”
• EWWW Image Optimizer, “Basic Configuration”
• EWWW Image Optimizer, “Getting Started”
• Make WordPress Core, “Performance improvements for images in WordPress 4.5”

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.