Chunked transfer encoding is a streaming data transfer mechanism available in Hypertext Transfer Protocol (HTTP) version 1.1, defined in RFC 9112 §7.1. In chunked transfer encoding, the data stream is divided into a series of non-overlapping "chunks". The chunks are sent out and received independently of one another. At any given time, no knowledge of the data stream outside the currently-being-processed chunk is necessary for either the sender or the receiver. Each chunk is preceded by its size in bytes and transmission ends when a zero-length chunk is received. The chunked keyword in the Transfer-Encoding header is used to indicate chunked transfer. Chunked transfer encoding is not supported in HTTP/2, which provides its own mechanisms for data streaming. == Rationale == The introduction of chunked encoding provided various benefits: Chunked transfer encoding allows a server to maintain an HTTP persistent connection for dynamically generated content. In this case, the HTTP Content-Length header cannot be used to delimit the content and the next HTTP request/response, as the content size is not yet known. Chunked encoding has the benefit that it is not necessary to generate the full content before writing the header, as it allows streaming of content as chunks and explicitly signaling the end of the content, making the connection available for the next HTTP request/response. Chunked encoding allows the sender to send additional header fields after the message body. This is important in cases where values of a field cannot be known until the content has been produced, such as when the content of the message must be digitally signed. Without chunked encoding, the sender would have to buffer the content until it was complete in order to calculate a field value and send it before the content. == Applicability == For version 1.1 of the HTTP protocol, the chunked transfer mechanism is considered to be always and anyway acceptable, even if not listed in the Transfer-Encoding (TE) request header field, and when used with other transfer mechanisms, should always be applied last to the transferred data and never more than one time. This transfer encoding method also allows additional entity header fields to be sent after the last chunk if the client specified the "trailers" parameter as an argument of the TE request field. The origin server of the response can also decide to send additional entity trailers even if the client did not specify the "trailers" parameter, but only if the metadata is optional (i.e. the client can use the received entity without them). Whenever the trailers are used, the server should list their names in the Trailer header field; three header field types are specifically prohibited from appearing as a trailer field: Content-Length, Trailer, and Transfer-Encoding. == Format == If a Transfer-Encoding field with a value of "chunked" is specified in an HTTP message (either a request sent by a client or the response from the server), the body of the message consists of one or more chunks and one terminating chunk with an optional trailer before the final ␍␊ sequence (i.e. carriage return followed by line feed). Each chunk starts with the number of octets of the data it embeds expressed as a hexadecimal number in ASCII followed by optional parameters (chunk extension) and a terminating ␍␊ sequence, followed by the chunk data. The chunk is terminated by ␍␊. If chunk extensions are provided, the chunk size is terminated by a semicolon and followed by the parameters, each also delimited by semicolons. Each parameter is encoded as an extension name followed by an optional equal sign and value. These parameters could be used for a running message digest or digital signature, or to indicate an estimated transfer progress, for instance. The terminating chunk is a special chunk of zero length. It may contain a trailer, which consists of a (possibly empty) sequence of entity header fields. Normally, such header fields would be sent in the message's header; however, it may be more efficient to determine them after processing the entire message entity. In that case, it is useful to send those headers in the trailer. Header fields that regulate the use of trailers are Transfer-Encoding with the "trailers" parameter (used in requests) and Trailer (used in responses). == Use with compression == HTTP servers often use compression to optimize transmission, for example with Content-Encoding: gzip or Content-Encoding: deflate. If both compression and chunked encoding are enabled, then the content stream is first compressed, then chunked; so the chunk encoding itself is not compressed, and the data in each chunk is compressed holistically (i.e. based on the whole content). The remote endpoint then decodes the stream by concatenating the chunks and uncompressing the result. == Example == === Encoded data === The following example contains three chunks of size 4, 7, and 11 (hexadecimal "B") octets of data. 4␍␊Wiki␍␊7␍␊pedia i␍␊B␍␊n ␍␊chunks.␍␊0␍␊␍␊ Below is an annotated version of the encoded data. 4␍␊ (chunk size is four octets) Wiki (four octets of data) ␍␊ (end of chunk) 7␍␊ (chunk size is seven octets) pedia i (seven octets of data) ␍␊ (end of chunk) B␍␊ (chunk size is eleven octets) n ␍␊chunks. (eleven octets of data) ␍␊ (end of chunk) 0␍␊ (chunk size is zero octets, no more chunks) ␍␊ (end of final chunk with zero data octets) Note: Each chunk's size excludes the two ␍␊ bytes that terminate the data of each chunk. === Decoded data === Decoding the above example produces the following octets: Wikipedia in ␍␊chunks. The bytes above are typically displayed as Wikipedia in chunks.
Color clock
The color clock, or color timer, is a part of the video circuitry of computer graphics hardware that works with analog color television systems. The clock is timed to match the timing of the color standard it works with, typically NTSC or PAL, ensuring that the data being read from the computer memory to create the image on-screen is in sync with the display. Depending on the speed of the color clock, the product of the resolution and number of colors is defined. Slow color clocks of many early games consoles and home computers resulted in limited color palettes at the highest resolutions.
CSS box model
In web development, the CSS box model refers to how HTML elements are modeled in browser engines and how the dimensions of those HTML elements are derived from CSS properties. It is a fundamental concept for the composition of HTML webpages. The guidelines of the box model are described by web standards World Wide Web Consortium (W3C) specifically the CSS Working Group. For much of the late-1990s and early 2000s there had been non-standard compliant implementations of the box model in mainstream browsers. With the advent of CSS2 in 1998, which introduced the box-sizing property, the problem had mostly been resolved. == Specifics == The Cascading Style Sheets (CSS) specification describes how elements of web pages are displayed by graphical browsers. Section 4 of the CSS1 specification defines a "formatting model" that gives block-level elements—such as p and blockquote—a width and height, and three levels of boxes surrounding it: padding, borders, and margins. While the specification never uses the term "box model" explicitly, the term has become widely used by web developers and web browser vendors. All HTML elements can be considered "boxes", this includes div tag, p tag, or a tag. Each of those boxes has five modifiable dimensions: the height and width describe dimensions of the actual content of the box (text, images, ...) the padding describes the space between this content and the border of the box the border is any kind of line (solid, dotted, dashed...) surrounding the box, if present the margin is the space around the border According to the CSS1 specification, released by W3C in 1996 and revised in 1999, when a width or height is explicitly specified for any block-level element, it should determine only the width or height of the visible element, with the padding, borders, and margins applied afterward. Before CSS3, this box model was known as W3C box model, in CSS3, it is known as the content-box. The total width of a box is therefore margin-left + border-left + padding-left + width + padding-right + border-right + margin-right. Similarly, the total height of a box equals margin-top + border-top + padding-top + height + padding-bottom + border-bottom + margin-bottom. For example, the following CSS code would specify the box dimensions of each block belonging to 'my-class'. Moreover, each such box will have total height 140px and width 240px. CSS3 introduced the Internet Explorer box model to the standard, known referred to as border-box. == History == Before HTML 4 and CSS, very few HTML elements supported both border and padding, so the definition of the width and height of an element was not very contentious. However, it varied depending on the element. The HTML width attribute of a table defined the width of the table including its border. On the other hand, the HTML width attribute of an image defined the width of the image itself (inside any border). The only element to support padding in those early days was the table cell. Width for the cell was defined as "the suggested width for a cell content in pixels excluding the cell padding." In 1996, CSS introduced margin, border and padding for many more elements. It adopted a definition width in relation to content, border, margin and padding similar to that for a table cell. This has since become known as the W3C box model. At the time, very few browser vendors implemented the W3C box model to the letter. The two major browsers at the time, Netscape 4.0 and Internet Explorer 4.0 both defined width and height as the distance from border to border. This has been referred to as the traditional or the Internet Explorer box model. Internet Explorer in "quirks mode" includes the content, padding and borders within a specified width or height; this results in a narrower or shorter rendering of a box than would result following the standard behavior. The Internet Explorer box model behavior was often considered a bug, because of the way in which earlier versions of Internet Explorer handle the box model or sizing of elements in a web page, which differs from the standard way recommended by the W3C for the Cascading Style Sheets language. As of Internet Explorer 6, the browser supports an alternative rendering mode (called the "standards-compliant mode") which solves this discrepancy. However, for backward compatibility reasons, all versions still behave in the usual, non-standard way by default (see quirks mode). Internet Explorer for Mac is not affected by this non-standard behavior. === Workarounds === Internet Explorer versions 6 and onward are not affected by the bug if the page contains certain HTML document type declarations. These versions maintain the buggy behavior when in quirks mode for reasons of backward compatibility. For example, quirks mode is triggered: When the document type declaration is absent or incomplete; When an HTML 3 or earlier document is encountered; When an HTML 4.0 Transitional or Frameset document type declaration is used and a system identifier (URI) is not present; When an SGML comment or other unrecognized content appears before the document type declaration Internet Explorer 6 also uses quirks mode if there is an XML declaration prior to the document type declaration. Various workarounds have been devised to force Internet Explorer versions 5 and earlier to display Web pages using the W3C box model. These workarounds generally exploit unrelated bugs in Internet Explorer's CSS selector processing in order to hide certain rules from the browser. The best known of these workarounds is the "box model hack" developed by Tantek Çelik, a former Microsoft employee who developed this idea while working on Internet Explorer for the Macintosh. It involves specifying a width declaration for Internet Explorer for Windows, and then overriding it with another width declaration for CSS-compliant browsers. This second declaration is hidden from Internet Explorer for Windows by exploiting other bugs in the way that it parses CSS rules. The implementation of these CSS “hacks” has been further complicated by the public release of Internet Explorer 7, which has had some issues fixed, but not others, causing undesired results in pages using these hacks. Box model hacks have proven unreliable because they rely on bugs in browsers' CSS support that may be fixed in later versions. For this reason, some Web developers have instead recommended either avoiding specifying both width and padding for the same element or using conditional comment and/or CSS filters to work around the box model bug in older versions of Internet Explorer. == Support for Internet Explorer's box model == Web designer Doug Bowman has said that the original Internet Explorer box model represents a better, more logical approach. Peter-Paul Koch gives the example of a physical box, whose dimensions always refer to the box itself, including potential padding, but never its content. He says that this box model is more useful for graphic designers, who create designs based on the visible width of boxes rather than the width of their content. Bernie Zimmermann says that the Internet Explorer box model is closer to the definition of cell dimensions and padding used in the HTML table model. The W3C has included a "box-sizing" property in CSS3. When box-sizing: border-box; is specified for an element, any padding or border of the element is drawn inside the specified width and height, "as commonly implemented by legacy HTML user agents". Internet Explorer 8, WebKit browsers such as Apple Safari 5.1+ and Google Chrome, Gecko-based browsers such as Mozilla Firefox 29.0 and later, Opera 7.0 and later, and Konqueror 3.3.2 and later support the CSS3 box-sizing property. Gecko browsers previous than 29.0 support the same functionality using the browser-specific -moz-box-sizing property. border-box is the default box model used in Bootstrap framework.
FactorDaily
FactorDaily is an Indian digital media publication founded in 2016 by Pankaj Mishra and Jayadevan PK. Mishra was formerly an Editor at TechCrunch and the Economic Times. The digital publication was launched with an intent to produce stories on the impact of technology on life in India. == History == FactorDaily began publishing in May 2016, with daily reported stories on technology, culture and life in India. Prior to its launch, the company had raised $1 million in seed funding from Accel India, Blume Ventures, Girish Mathrubootham of Freshdesk, Vijay Shekhar Sharma of PayTm, and Jay Vijayan of Tekion. Josey Puliyenthuruthel John, formerly Managing Editor at Business Today and National Corporate Editor at Mint, later joined the company as a Consulting Editor. In January 2017, FactorDaily launched its first Podcast called The Outliers. The inaugural episode featured a conversation with Manish Sharma of Printo on his journey starting up. == Awards == The FactorDaily team won the Bengaluru Editors Lab 2017, a journalism hackathon organised by the Global Editors Network (GEN). The story titled "India has 3,800 psychiatrists for 1.2bn people. Can tech step in to manage mental health?" won the first prize in the online category of the fifth Schizophrenia Research Foundation’s (SCARF) ‘Media for Mental Health’ awards. The story titled 'The dark hand of tech that stokes sex trafficking in India', won the Stop Slavery media Awards by the Thomson Reuters Foundation for the year 2020.
Content Credentials
Content Credentials (also known as C2PA signatures) are a digital media metadata specification. They aim to provide provenance information about a piece of media (such as an image or a video) and help prove its authenticity. They are described as the equivalent of nutrition labels for digital media. One of the stated goal of this specification is to fight online disinformation. The specification is written and maintained by the Coalition for Content Provenance and Authenticity (C2PA), a group of many media and tech organizations including Adobe, Amazon, the BBC, Google, Meta, Microsoft, OpenAI and Sony. Another organization, the Content Authenticity Initiative (CAI), is responsible for promoting the standard and accelerate its adoption. The standard relies on cryptographic digital signatures. == Adoption == There are two main stakeholders who can implement Content Credentials: Producers (softwares and hardwares that produce or modify digital media) and publishers (softwares that show digital media to users). === Producers === ==== Adobe ==== Adobe is one of the first companies to implement the specification, announcing support in Photoshop in 2021. Content Credentials can be enabled and the complete history of edits is kept. ==== Google ==== Google announced support for Content Credentials on its Pixel 10 phones in August 2025. The Content Credentials are embedded on each picture taken from the Pixel Camera, and modifications done using Google Photos. Information include picture timestamp and a non-identifiable signature that proves it was taken from a Pixel 10. As for Google Photos, a list of AI and non-AI edits are kept. Google is the first company to introduce support for Content Credentials on either phones or consumer-grade devices, and also the first company to make it available for free to all users. ==== Nikon ==== Nikon announced in 2024 that their Z6 III camera would support embedding Content Credentials in its photos. However, in 2025, a vulnerability was discovered in the software of the camera that allowed to combine unauthentic images with authentic photos and still have the resulting image with a valid digital signature. Nikon revoked the certificates. ==== Media organizations ==== CBC/Radio-Canada and the BBC both have started attaching Content Credentials to media they produce or verify. ==== OpenAI ==== OpenAI embeds Content Credentials on the images and videos it generates that includes that the media was created by AI using their platforms. ==== Sony ==== In June 2025, Sony announced the release of its Camera Verify system for press photographers and news editors using C2PA digital signatures. Initially, the system will be limited to still images, high‑end cameras, and selected news agencies. Registration with Sony Creators' Cloud is also required. === Publishers === ==== LinkedIn ==== In 2024, LinkedIn started showing a "CR" icon on images that contain Content Credentials of AI-generated images. In 2025, they announced a partnership with Adobe to allow photographers to prove ownership of images using Content Credentials. ==== TikTok ==== TikTok announced in 2024 that an "AI-generated" label would be applied to videos containing Content Credentials if they were AI-generated. In 2025, they announced that users could control the amount of AI-generated content they see, using self-reported labels, Content Credentials and an invisible, proprietary AI watermark embedded in videos by their AI editor tool. ==== YouTube ==== In 2024, YouTube started showing to users a label that reads "captured with a camera" on videos that show authentic, unedited videos taken by Content Credentials-compatible cameras.
Art Recognition
Art Recognition is a Swiss technology company headquartered in Adliswil, within the Zurich metropolitan area, Switzerland. Art Recognition specializes in the application of artificial intelligence (AI) for art authentication and the detection of art forgeries. == Overview == Art Recognition was established in 2019 by Dr. Carina Popovici and Christiane Hoppe-Oehl. Art Recognition employs a combination of machine learning techniques, computer vision algorithms, and deep neural networks to assess the authenticity of artworks. The company's technology undergoes a process of data collection, dataset preparation, and training. === Academic partnerships and grants === Art Recognition has established a relationship with Innosuisse, a Swiss innovation agency, to expand its research and development initiatives. It has also formed a strategic collaboration with Nils Büttner, an art historian and professor at the State Academy of Fine Arts Stuttgart (ABK Stuttgart). === Notable developments === In May 2024, Art Recognition played a key role in identifying counterfeit artworks, including alleged Monets and Renoirs, being sold on eBay. Germann Auction in November 2024 became the first auction house to successfully conduct a sale of artwork authenticated entirely by artificial intelligence. As of January 2025, Art Recognition has appointed art crime expert and Pulitzer Prize finalist Noah Charney as an advisor. === Recognition and debates === The company was featured on the front page of The Wall Street Journal for its involvement in the authentication case of the Flaget Madonna, believed to have been partly painted by Raphael. A broadcast by the Swiss public television SRF covered how the algorithm can be used to detect art forgeries with high accuracy. The technology developed by Art Recognition has been recognized for its role in providing a technology-based art authentication solution, compared to traditional methods. == Controversial cases == Art Recognition's AI algorithm has been applied to several high-profile and controversial artworks, sparking significant interest and debate in the art world. Samson and Delilah at the National Gallery in London: The National Gallery's "Samson and Delilah", traditionally attributed to the artist Rubens, has also been examined using Art Recognition's AI, which has assessed the painting as non-authentic. De Brecy Tondo Madonna. A research team from Bradford University and the University of Nottingham initially attributed the painting to Raphael, employing an AI face recognition software, while the AI developed at Art Recognition returned a negative result. The Bradford group's AI was trained on 49 images, whereas Art Recognition employed a larger dataset of over 100 images. Lucian Freud Painting Controversy: Featured in The New Yorker, a painting attributed to Lucian Freud became a subject of dispute. Art Recognition's AI analysis played a big role in examining the painting's authenticity. Titian at Kunsthaus Zürich: A painting attributed to Titian, housed at Kunsthaus Zürich, has been a topic of debate among art experts. The application of Art Recognition's technology offered a new perspective. Following this debate, Kunsthaus Zürich has announced plans to initiate a comprehensive project aimed at resolving the authenticity questions surrounding the painting. Art Recognition has contributed to the authentication debate surrounding The Polish Rider, a painting traditionally attributed to Rembrandt but subject to scholarly debate.
Digital Cinema Initiatives
Digital Cinema Initiatives, LLC (DCI) is a consortium of major motion picture studios, formed to establish specifications for a common systems architecture for digital cinema systems. The organization was formed in March 2002 by Metro-Goldwyn-Mayer, Paramount Pictures, Sony Pictures, 20th Century Studios, Universal Studios, Walt Disney Studios and Warner Bros. Entertainment The primary purpose of DCI is to establish and document specifications for an open architecture for digital cinema that ensures a uniform and high level of technical performance, reliability and quality. By establishing a common set of content requirements, distributors, studios, exhibitors, d-cinema manufacturers and vendors can be assured of interoperability and compatibility. Because of the relationship of DCI to many of Hollywood's key studios, conformance to DCI's specifications is considered a requirement by software developers or equipment manufacturers targeting the digital cinema market. == Specification == On July 20, 2005, DCI released Version 1.0 of its "Digital Cinema System Specification", commonly referred to as the "DCI Specification". The document describes overall system requirements and specifications for digital cinema. Between March 28, 2006, and March 21, 2007, DCI issued 148 errata to Version 1.0. DCI released Version 1.1 of the DCI Specification on April 12, 2007, incorporating the previous 148 errata into the DCI Specification. On April 15, 2007, at the annual NAB Digital Cinema Summit, DCI announced the new version, as well as some future plans. They released the "Stereoscopic Digital Cinema Addendum" to begin to establish 3-D technical specifications in response to the popularity of 3-D stereoscopic films. It was also announced "which studios would take over the leadership roles in DCI after the current leadership term expires at the end of September." Subsequently, between August 27, 2007, and February 1, 2008, DCI issued 100 errata to Version 1.1. So, DCI released Version 1.2 of the DCI Specification on March 7, 2008, again incorporating the previous 100 errata into the specification document. An additional 96 errata were issued by August 30, 2012, so a revised Version 1.2 incorporating those additional errata was approved on October 10, 2012. DCI approved DCI Specification Version 1.3 on June 27, 2018, integrating the 45 errata issued to the previous version into a new document. On July 20, 2020, fifteen years to the day after Version 1.0, DCI issued a new DCI Specification Version 1.4 that assimilated 29 errata issued since Version 1.3. On October 13, 2021, DCI approved a new DCI Specification Version 1.4.1 that integrated the 23 errata that had been issued to DCI Specification Version 1.4. For the convenience of users, DCI also created an online HTML version of DCI Specification, Version 1.4.1. Due to the HTML conversion process, the footnotes in the DCSS now appear as endnotes. The PDF version contains pagination and page numbers whereas the HTML version does not. DCI Specification Version 1.4.2, dated June 15, 2022, includes revisions and refinements respecting Object-Based Audio Essence (OBAE), also known as Immersive Audio Bitstream (IAB). Version 1.4.2 also implements post-show log record collection utilizing SMPTE 430-17 SMS-OMB Communications Protocol Specification. Additionally, Version 1.4.2 incorporated two prior addenda: the Digital Cinema Object-Based Audio Addendum, dated October 1, 2018 and the Stereoscopic Digital Cinema Addendum, Version 1.0, dated July 11, 2007. Users using Version 1.4.2 no longer need to refer to the separate addenda. Previous DCSS versions are archived on the DCI web site. Based on many SMPTE and ISO standards, such as JPEG 2000-compressed image and "broadcast wave" PCM/WAV sound, the DCI Specification explains the route to create an entire Digital Cinema Package (DCP) from a raw collection of files known as the Digital Cinema Distribution Master (DCDM), as well as the specifics of its content protection, encryption, and forensic marking. The DCI Specification also establishes standards for the decoder requirements and the presentation environment itself, such as ambient light levels, pixel aspect and shape, image luminance, white point chromaticity, and those tolerances to be kept. Even though it specifies what kind of information is required, the DCI Specification does not include specific information about how data within a distribution package is to be formatted. Formatting of this information is defined by the Society of Motion Picture and Television Engineers (SMPTE) digital cinema standards and related documents. == Image and audio capability overview == === 2D image === 2048×1080 (2K) at 24 frame/s or 48 frame/s, or 4096×2160 (4K) at 24 frame/s In 2K, for Scope (2.39:1) presentation 2048×858 pixels of the imager is used In 2K, for Flat (1.85:1) presentation 1998×1080 pixels of the imager is used In 4K, for Scope (2.39:1) presentation 4096×1716 pixels of the imager is used In 4K, for Flat (1.85:1) presentation 3996×2160 pixels of the imager is used 12 bits per color component (36 bits per pixel) via dual HD-SDI (encrypted) 10 bits only permitted for 2K at 48 frame/s CIE XYZ color space, gamma-corrected TIFF 6.0 container format (one file per frame) JPEG 2000 compression From 0 to 5 or from 1 to 6 wavelet decomposition levels for 2K or 4K resolutions, respectively Compression rate of 4.71 bits/pixel (2K @ 24 frame/s), 2.35 bits/pixel (2K @ 48 frame/s), 1.17 bits/pixel (4K @ 24 frame/s) 250 Mbit/s maximum image bit rate === Stereoscopic 3D image === 2048×1080 (2K) at 48 frame/s - 24 frame/s per eye (4096×2160 4K not supported) In 2K, for Scope (2.39:1) presentation 2048×858 pixels of the imager is used In 2K, for Flat (1.85:1) presentation 1998×1080 pixels of the imager is used Optionally, in the HD-SDI link only: 12 bit color, YCxCz 4:2:2 (i.e. chroma subsampling in XYZ space), each eye in separate stream === Audio === 24 bits per sample, 48 kHz or 96 kHz Up to 16 channels WAV container, uncompressed PCM DCI has additionally published a document outlining recommended practice for High Frame Rate digital cinema. This document discloses the following proposed frame rates: 60, 96, and 120 frames per second for 2D at 2K resolution; 48 and 60 for stereoscopic 3D at 2K resolution; 48 and 60 for 2D at 4K resolution. The maximum compressed bit rate for support of all proposed frame rates should be 500 Mbit/s. == Related information == The idea for DCI was originally mooted in late 1999 by Tom McGrath, then COO of Paramount Pictures, who applied to the U.S. Department of Justice for anti-trust waivers to allow the joint cooperation of all seven major motion picture studios. Universal Pictures made one of the first feature-length DCPs created to DCI specifications, using their film Serenity. Although it was not distributed theatrically, it had one public screening on November 7, 2005, at the USC Entertainment Technology Center's Digital Cinema Laboratory in the Pacific Theatre, Hollywood. Inside Man (2006) was Universal's first DCP commercial release, and, in addition to 35mm film distribution, was delivered via hard drive to 20 theatres in the United States along with two trailers. The Academy Film Archive houses the Digital Cinema Initiatives, LLC Collection, which includes film and digital elements from DCI's Standard Evaluation Material (StEM), a 12-minute production shot on 35mm and 65mm film, created for vendors and standards organizations to test and evaluate image compression and digital projection technologies.