Connected-component labeling assigns an identifying number to each separate connected region of an image after choosing which pixels belong to the foreground and which neighboring pixels count as connected. In a binary image, interpret each foreground pixel as a vertex of a graph, with an edge for each allowed neighboring pair. Each component receives one label; background pixels receive a separate background value. The choice of pixel connectivity is part of the problem definition, not an incidental display setting.

For example, consider the binary imageIf a foreground pixel connects only to foreground pixels immediately above, below, left or right, the two ones form two regions. One valid label image is $\left(\begin{array}{cc}1& 0\\ 0& 2\end{array}\right)$. If diagonal neighbors also connect, the same input has one region, with label image $\left(\begin{array}{cc}1& 0\\ 0& 1\end{array}\right)$. SciPy's ndimage.label treats zero as background and nonzero entries as foreground; its default two-dimensional neighborhood uses the four axial neighbors. Its neighborhood mask must be symmetric about its centre so that a connection works in both directions.^[ref]

One direct algorithm scans for an unlabelled foreground pixel, starts a flood fill there and assigns a fresh label to every reachable foreground pixel. It then resumes scanning for another unlabelled region. For a fixed-size neighborhood, every pixel and a bounded number of neighbors need be inspected, giving $O(N)$ time complexity for $N$ image pixels, with storage for labels and the pending search. Another approach records provisional labels and merges equivalent ones using a disjoint-set data structure.

The numerical labels are identifiers: swapping labels $1$ and $2$ does not change the segmentation. A single printed character can have several disconnected regions, while touching characters can share one region. Connected-component labeling therefore supplies geometric grouping for image segmentation and optical character recognition; it does not itself determine what an object means.

A binary image assigns one of two values to every pixel, commonly $0$ and $1$ or false and true. It can represent a selected region, such as marks separated from a page background, without retaining all the original brightness values. The two values express a chosen classification of pixels, not necessarily two physical colors in the original scene.

For example, define image thresholding by selecting intensities at least $100$:The output preserves which side of the threshold each value occupied but loses the distinction between $120$ and $150$. Changing the threshold changes the selected region, so interpreting the result requires the selection rule as well as the image.

A binary image is useful as input to connected-component labeling. There, pixel connectivity determines whether diagonally touching selected pixels belong to the same region. SciPy's labeling operation accepts zero as background and all nonzero values as foreground; an input with several nonzero intensities is consequently treated as a foreground mask by that particular API.^[ref]

Two possibilities require one bit of information per pixel in a direct packed representation. An actual array or image file can use more storage, or compression can exploit repeated patterns. Also distinguish a binary image from a label image containing several region identifiers: a label value of three need not mean brighter foreground than a label value of one.

Image thresholding classifies pixels by comparing their intensities with a threshold, often producing a binary image. A global threshold uses the same value throughout the image; adaptive thresholding permits the threshold to depend on position and nearby intensities.^[ref]

For example, defineIntensities $99,100,101$ then become $0,0,1$. The comparison at equality matters: a rule using $I\ge 100$ would instead give $0,1,1$. OpenCV's THRESH_BINARY uses the strict greater-than rule, assigning its chosen maximum output value only above the threshold.^[ref]

Threshold choice affects which distinctions survive. Two different bright intensities can become the same foreground value, while a small change near the boundary can change a pixel's classification. The resulting mask can then feed connected-component labeling, where pixel connectivity separately decides which selected pixels form a region.

A useful motivating experiment keeps one image of dark marks fixed while adding or recording a gradual illumination variation across the background. Compare a global threshold with a declared local-neighborhood rule, inspecting lost strokes and falsely selected background. OpenCV documents local mean and Gaussian-weighted rules with an offset; this addresses varying illumination rather than proving that every resulting region is a meaningful object.^[ref]

A histogram can guide global selection, but intensity statistics alone do not determine semantic identity. Noise and overlapping foreground/background intensities can make every threshold imperfect. Report the input representation, comparison convention and any filtering or local-window settings so that a thresholded result can be reproduced.

An HTTP request is a message asking a server to apply an HTTP request method to a target resource. It includes control information and HTTP header fields, and can include content according to the applicable method and message rules. Its meaning is distinct from the textual framing used by one protocol version.^[ref]

For an illustrative HTTP/1.1 request, the line GET /color?view=plain HTTP/1.1 selects a method and request target, while Host: example.org supplies host information. An empty line ends the header section. These pieces belong to the version's request-line and field syntax.^[ref]

Starting from https://example.org/color?view=plain#legend, the ordinary origin-form target is /color?view=plain. The query string participates in that target, while the fragment identifier does not: fragment processing is performed on the client side rather than by including the fragment in the target sent to the server.^[ref][ref]

The method cannot be inferred from a content string alone. Sending the text blue to an endpoint stipulated to replace a color and sending it to an endpoint stipulated to append a log entry request different operations. The target, method and application contract supply that distinction.

An HTTP request also differs from a returned HTTP response. A successfully transmitted request can receive an error status, and a connection can end before a final response is obtained. Reasoning about the requested operation, its eventual outcome and the transport event as separate observations makes failures easier to interpret.

An HTTP response is a message returned in response to an HTTP request, carrying an HTTP status code, associated HTTP header fields and any permitted content. An exchange can include informational responses before its final response.^[ref]

For an invented plain-text resource, a successful GET can return status 200, Content-Type: text/plain; charset=utf-8 and the content blue. These four letters occupy four bytes in UTF-8, so a corresponding content length is four. The HTTP representation's data, its media type and the status describing this exchange have different roles.

A response need not contain a representation body. A successful PUT can return 204 without response content, and a HEAD response carries no content even when the corresponding GET would retrieve data. Interpreting a response therefore requires the request method as well as the status code.^[ref]

In HTTP/1.1, HTTP/1.1 200 OK is a possible status line, followed by field lines, an empty line and any message body allowed by the framing rules. This spelling is one version's concrete syntax for the broader response abstraction.^[ref]

The received content can change between requests while the resource identifier stays the same. Conversely, the same content can accompany different exchange metadata. Inspect status, fields and content together instead of treating any one of them as the entire response or as a guarantee of an application-specific result.

An HTTP status code is a three-digit code in an HTTP response describing the outcome or progress of handling an HTTP request. Its first digit identifies a broad class: informational 1xx, successful 2xx, redirection 3xx, client-error 4xx or server-error 5xx. The particular code and request method refine the meaning.^[ref]

For an invented /color resource, a PUT can store blue and return 204 to indicate successful fulfillment without response content. A later GET can return 200 with the text blue. A HEAD response can also have status 200 while carrying no response content. Thus a successful code does not by itself determine whether there is a body to read.^[ref]

In HTTP/1.1, a status line might be written HTTP/1.1 200 OK. The numerical code supplies the standardized status; the accompanying reason phrase is optional and is not the authority for interpretation. Changing the descriptive phrase does not redefine code 200.^[ref]

An HTTP status code describes this exchange rather than proving that every application-level goal succeeded. A request can be transferred correctly and still receive an error status. Conversely, receiving 200 does not establish that an application-specific calculation inside the returned content is correct. Interpret status, HTTP header fields, content and the application's contract together.

An HTTP header field is named information carried in an HTTP message's header section. Its definition determines how its value is interpreted. Field names are case-insensitive, while values follow the rules of their particular field rather than one universal casing rule.^[ref]

For example, ETag: "AbC" and etag: "abc" use the same field name but different entity tags. The quoted opaque strings are compared character by character under the relevant tag-comparison rules. Lowercasing both names is harmless for identifying the field; lowercasing all values would erase a real distinction.^[ref]

Other fields express different kinds of information. Content-Type: text/plain; charset=utf-8 describes a media type and character encoding for content. It does not contain the content itself, and its meaning cannot be inferred by applying the entity-tag grammar to it.

In HTTP/1.1, a textual field line places a colon between the name and value; an empty line terminates the header section. This is a wire-format example, not a requirement that every HTTP version transmit identical text lines.^[ref]

Repeated field occurrences also need their own semantics. Some can be combined as ordered lists, but treating every header section as a dictionary with exactly one value per name can lose information. Read the field definition before combining lines or rearranging values.^[ref]

An HTTP request method identifies the operation requested for an HTTP request's target. The target and method have separate roles: the same resource can be read, replaced or processed according to the chosen method and its defined semantics. Method tokens are case-sensitive.^[ref]

For example, an invented /color resource uses GET to retrieve its current color and PUT to replace that color with the supplied value. One PUT storing blue and two identical such operations leave the same intended color. A different /log resource is stipulated to append each POST value: two appends of x then produce two entries. The append behavior belongs to this example application; it is not a universal definition of every POST.

HTTP idempotence concerns repeated intended effects, not identical response messages. A repeated replacement can leave the same state while returning a different HTTP status code because the resource already exists. An HTTP safe method requests essentially read-only semantics; incidental activities such as logging do not make every safe request a request to change the resource.^[ref]

Cacheability is another property, governed by method and response rules rather than by idempotence alone. Interpret the HTTP request method, HTTP header fields and HTTP response together before deciding what a repeated or cached exchange means.^[ref]

An HTTP representation consists of data and metadata describing a selected state or form of a resource. It is the information transferred or referenced to express that resource, rather than the resource identifier itself. A resource can have more than one available representation.^[ref]

For an invented /color resource, one representation is the plain-text bytes blue with type text/plain. Another is an HTML document displaying the same color information, with type text/html. The underlying application value can agree while the bytes and media types differ. HTTP content negotiation can help select among available representations according to request information.

An HTTP response also contains control information about the exchange, such as its HTTP status code. It is not simply another name for representation data. A HEAD response, for example, can describe a selected representation without transferring its content, while a GET can transfer that content.^[ref]

Representation metadata tells a recipient how to interpret the data. A media type concerns format, character-set information concerns text encoding, and an entity tag supplies a validator for the selected representation. These properties can differ between two forms of the same resource.

A URL therefore does not promise one immutable byte sequence. A resource can change with time or offer different forms; conversely, matching application meaning does not require byte-identical representations. When comparing responses, record which representation was selected and compare the relevant data and metadata rather than only the identifier.

HTTP/1.1 is a version of the Hypertext Transfer Protocol with a specified message syntax, parsing rules and connection behavior. Its shared method and status meanings come from the broader HTTP semantics; its concrete messages use a start line, field lines, an empty line and any permitted message body.^[ref]

A short response can be represented with visible escape notation as HTTP/1.1 200 OK\r\nContent-Length: 4\r\n\r\nblue. Here \r\n denotes the carriage-return/line-feed pair in the actual byte stream, rather than four literal characters. The body is the four bytes spelling blue; the empty line separates it from the header section.

This illustrates HTTP message framing: a recipient needs rules for locating the end of one message before interpreting subsequent bytes. In this example, the declared content length identifies four body bytes. Other permitted cases have their own framing rules; a line break inside body data is not automatically a new message.^[ref]

An HTTP persistent connection can carry multiple exchanges rather than requiring a fresh connection for each message. Persistence does not imply that a previous request's method or target is silently inherited by the next one; each request still has its own defined control information.^[ref]

Distinguish this wire format from the abstract HTTP request and HTTP response. A different HTTP version can encode control information differently while retaining shared meanings such as GET or status 200. Likewise, the protocol version alone does not identify the media type of a returned representation.

An HTTP conditional request carries one or more preconditions to be evaluated before applying its HTTP request method. The condition can ask whether the selected HTTP representation still has a previously observed entity tag. This makes the request depend on the state the client knows, rather than applying an operation unconditionally.^[ref]

For HTTP cache validation, suppose an earlier retrieval of /color stored the text blue with entity tag "v7". A later GET with If-None-Match: "v7" asks for the representation only if its tag no longer matches. If the selected representation still matches, the condition is false and the server returns status 304 instead of transferring the representation data again. If it has changed, an otherwise successful retrieval can return the new data.^[ref]

A second use prevents overwriting another client's work. Suppose two clients read version "v7". The first makes an update and the server assigns version "v8". The second submits a different PUT with If-Match: "v7". The stale tag does not match, so the server must not apply that update; in this example it returns 412. Checking and applying the condition as part of the operation prevents the second client from silently replacing the first client's changes.^[ref]

The two field names deliberately use different comparisons: If-Match requires strong entity tag comparison, while If-None-Match uses weak comparison and can match a weak entity tag. Failed If-Match need not always yield 412: the specification permits a success response when the requested change appears already applied. Authentication, redirects and other normal request checks also precede precondition evaluation. An HTTP conditional request therefore combines method semantics, a particular condition and the specified evaluation order.

HTTP message framing determines where an HTTP request or HTTP response ends and whether it is complete. The concrete rules depend on the protocol version. In HTTP/1.1, an empty line ends the header section, but the end of the message body requires the applicable length, transfer-coding or connection rules. A body can itself contain line breaks.^[ref]

Consider an ordinary successful response to GET whose text is café in UTF-8. Its four displayed letters occupy five octets, with hexadecimal values 63 61 66 c3 a9. With no transfer coding and no overriding bodyless-response rule, Content-Length: 5 therefore frames this body. Counting displayed characters would give the wrong boundary.^[ref]

An alternative is chunked transfer coding. Use Transfer-Encoding: chunked instead of the content-length field. The body can then be written in visible escape notation as 2\r\nca\r\n3\r\nfé\r\n0\r\n\r\n. Here \r\n denotes an actual carriage-return/line-feed pair, and the text is encoded in UTF-8. The first chunk supplies two octets; the second supplies three; the zero-sized chunk and empty trailer section finish the coding. This transfer-coded body occupies twenty octets and yields the same five content octets after decoding.^[ref]

Precedence matters. Responses to HEAD and responses with status 1xx, 204 or 304 have no message body even when fields appear to suggest a length. Some responses instead end with connection closure; requests are not close-delimited. Receiving fewer than the declared number of octets leaves a length-delimited message incomplete.^[ref]

Framing is separate from media type: a recipient first needs to delimit the transmitted data, then interpret its format. It also makes HTTP persistent connections possible, since a recipient can finish one exchange without treating connection closure as the only indication of completion.

An HTTP persistent connection carries more than one HTTP request/HTTP response exchange over the same connection. HTTP/1.1 uses persistence by default unless its connection rules indicate closure. Reusing the connection avoids establishing a separate connection for every exchange.^[ref]

For a sequential example, a client retrieves /color and reads a response with Content-Length: 4 followed by blue. It then requests /shape on the same connection and reads Content-Length: 6 followed by circle. These are two distinct requests and two distinct responses, each with its own control information and HTTP message framing. Neither resource name nor method is inherited merely because the connection is reused.

This example relies on being able to finish the first message without closing the connection. To retain persistence, the message lengths must be self-defined rather than delimited by closure. A server must read the complete request body or close the connection after responding; otherwise leftover body bytes could be mistaken for a new request. A client likewise must consume the complete response body before reusing the connection.^[ref]

Connection: close signals that the connection will close after the current response. Persistence is not a promise of an unlimited lifetime: a connection can also close unexpectedly. Whether an outstanding operation can be retried automatically depends on its semantics, particularly HTTP idempotence, rather than on the fact that the connection had previously been reusable.^[ref]

Persistence also does not require sending requests before earlier responses arrive. That additional option is HTTP pipelining; in HTTP/1.1, the corresponding responses must retain request order. The sequential example uses persistence without pipelining.^[ref]

HTTP freshness describes whether a stored HTTP response is young enough for reuse according to its applicable lifetime. The comparison isThe strict inequality matters: a response exactly at its lifetime boundary is no longer fresh.^[ref]

The HTTP freshness lifetime can come from explicit cache controls or, where permitted, a heuristic. The HTTP current age accounts for age accumulated before the response entered the present cache as well as its residence there. Counting only the seconds since this cache received the response can therefore underestimate its age.^[ref]

For an own example, suppose the applicable lifetime is $60$ seconds and the correctly calculated current age at a chosen instant is $20$ seconds. Keep the lifetime fixed. After another $30$ seconds, the age is $50$, so $60>50$ and the response remains fresh. After another $40$ seconds from the original instant, the age is $60$ and the strict comparison fails. After $45$ seconds it is $65$, again stale. These calculations start from a given current age; they do not derive it from local residence time alone.

Freshness and HTTP cache validation answer different questions. An old response might still match the origin's present HTTP representation. Validation can establish that reuse remains appropriate without retransmitting the representation body. Conversely, a fresh response has not thereby been checked against the origin at every use.^[ref]

Other rules still govern reuse. For example, the unqualified Cache-Control: no-cache response directive requires successful validation before subsequent use, even though the response can be stored. Stale-serving rules also have explicit conditions. A freshness calculation is therefore one part of deciding whether a stored HTTP response may satisfy a particular request, rather than a complete permission test.^[ref]

An HTTP trailer field is a message field carried in a trailer section after the content. It can provide metadata whose final value becomes available while the content is being generated or processed. Its placement lets a sender stream content before that metadata is complete.^[ref]

For a concrete HTTP/1.1 example, define an illustrative extension field Example-Count to report the number of content octets and explicitly permit it in trailers. This is a definition for the example, not a standard field. A response can announce Transfer-Encoding: chunked and Trailer: Example-Count in its header section. Its following transfer-coded body, using visible escape notation, is 3\r\nabc\r\n0\r\nExample-Count: 3\r\n\r\n.

Here \r\n denotes a carriage-return/line-feed pair in the actual stream. The three-octet chunk supplies abc. The zero-sized chunk ends the chunks, and Example-Count: 3 then supplies the trailer metadata before the final empty line. The content is just abc; the trailer field is not appended to the representation data.^[ref]

The initial Trailer field names metadata the sender anticipates sending. A recipient can use this announcement to prepare its processing, but it does not guarantee that every announced field will actually arrive. The field value itself remains in the later trailer section.^[ref]

Placement is constrained by semantics. A sender must know that a field's definition permits trailer use; fields needed earlier for HTTP message framing, routing or content interpretation generally cannot simply be moved to the end. A recipient must not merge trailer fields into the header section unless their definitions explicitly permit and define the merge.^[ref]

Trailers can also be discarded in transit, so an application cannot assume that arbitrary metadata placed there will reach or be acted upon by every recipient. Keeping HTTP trailer fields distinct from HTTP header fields preserves the distinction between information available before content processing and information learned afterwards.^[ref]

An HTTP private cache is dedicated to a single user. It is often implemented as part of a user agent, but its defining property is the single-user scope rather than a particular machine or storage medium. An HTTP shared cache can instead reuse responses for multiple users.^[ref]

Suppose a user's response carries Cache-Control: private, max-age=60. The unqualified private directive permits a private cache to store the response subject to the normal storage rules, while forbidding a shared cache from storing it. The max-age directive supplies its explicit HTTP freshness lifetime; it does not cancel the single-user storage restriction.^[ref]

If the correctly calculated HTTP current age is twenty seconds, sixty seconds exceeds that age and forty seconds remain until the freshness boundary. Reuse still requires matching the relevant request and satisfying other applicable constraints. At current age sixty, the strict freshness comparison fails; HTTP cache validation may then establish whether the stored representation remains suitable.^[ref]

Being private does not mean that every response must be stored or may be reused indefinitely. A cache can discard an entry, and an otherwise applicable restrictive directive remains significant. In particular, unqualified no-cache requires successful validation before subsequent reuse, whereas no-store prohibits the corresponding storage and reuse under its defined rules.^[ref]

The word private is also a cache-control distinction, not an encryption mechanism or a promise that the message is inaccessible to everyone else. The standard explicitly separates those meanings. Correct HTTP cache key selection and response handling still matter inside a single-user cache.^[ref]

For negotiated content, the stored representation can depend on request fields as well as the target. A private cache must therefore apply the same relevant matching rules rather than treating every request by its one user as interchangeable.

An HTTP shared cache stores HTTP responses for reuse by more than one user. It is often part of an intermediary, though that deployment is not required by the definition. An HTTP private cache is instead dedicated to a single user.^[ref]

For an own example, suppose four users request the same public manual through one shared cache. The first request obtains a complete, cacheable response with a $1200$-octet body. Assume the following three requests match the required HTTP cache key inputs, arrive while the stored response remains reusable, and have no directives requiring forwarding. They can be satisfied from that stored response. The origin then sends the body once instead of four times, avoiding $3(1200)=3600$ origin-body octets in this stipulated sequence. This does not count headers, validation traffic or delivery from the cache to the users.

Matching the target identifier alone need not be sufficient. If the response uses Vary: Accept, the relevant request-field matching rules also matter; one user's negotiated HTTP representation is not automatically suitable for another request's preferences.^[ref] HTTP content negotiation and cache selection therefore interact.

Storage and reuse are separate decisions. The unqualified Cache-Control: private response directive forbids storage by a shared cache. Other responses must still satisfy the ordinary storage constraints, and the cache must consider HTTP freshness or successful HTTP cache validation when constructing a later response.^[ref]

A shared cache also interprets s-maxage when present. For Cache-Control: max-age=600, s-maxage=60, its explicit freshness lifetime is sixty seconds rather than six hundred. This gives the origin a way to specify a shared reuse interval independently of the corresponding private-cache interval.^[ref]

The benefit comes from reusing an eligible response across users, not from assuming all users receive identical content. State selection inputs and cache controls before extrapolating the simple manual example to personalized or negotiated resources.