Four numbers are enough to describe a rectangle. There are nonetheless several incompatible ways of writing them, and moving from one to another produces errors that cannot be seen.This article compares those formats. It extends the article on small objects and dense scenes.
What each format holds
Five differences separate the common bounding box formats.The description of the rectangle, by its corners or by centre and dimensions.The unit of the values, in absolute pixels or as a fraction of the image.The organisation of files, one per image or else one for the whole corpus.The designation of classes, by their name or else by a number.And the space reserved for any additional attributes.One important practical consequence follows. Those five differences combine quite freely, two formats being able to differ on a single point or on all five, which makes a conversion that succeeded on one project wholly inapplicable as it stands on the next.What the directory format brings
Four characteristics distinguish a single file describing a whole bounding box corpus.Images and annotations are described there in a separate way.The classes are declared there once and for all.Additional attributes find their place there quite naturally.And the file quickly becomes bulky on a large corpus.One important observation follows for a bounding box project. The first characteristic settles on its own a problem the other formats leave entire, an image devoid of any object being described there explicitly, which removes the ambiguity between the empty image and the unprocessed one.What the file-per-image format brings
Four characteristics distinguish a file attached to each of the images.A short line per object, with no nested structure at all.Relative coordinates, perfectly insensitive to any resizing.Immediate reading by the simplest of tools.And no space provided for any attributes.One practical consequence follows. The last characteristic weighs far more than it appears to, a project needing an occlusion attribute having to encode it in the class or else give it up, which multiplies the classes or loses the information.What the format inherited from the document world brings
Four characteristics distinguish a tagged format, one file per image.An explicit structure where each of the values carries its name.Coordinates in pixels, readable without the slightest calculation.Fields already provided for difficulty as well as truncation.And a verbosity that appreciably burdens storage.One important practical consequence follows. The first characteristic makes it the most readable format for a human, every number there being accompanied by its meaning, which considerably reduces the risk of mistaken interpretation on a late reuse.What conversion can break
Five errors occur when moving from one bounding box format to another.A box centre interpreted as a corner.Relative values read as plain pixels.An origin of axes placed at the bottom rather than at the top.A class number shifted by one single unit.And a height purely swapped with a width.One observation follows. Those five errors share a formidable trait, the resulting file staying perfectly valid and the boxes keeping quite plausible dimensions, which lets the defect clear every automatic check.What visual verification catches
Four controls suffice after any bounding box conversion.A display of the boxes across a dozen images taken at random.A verification of the total count made before and then after.A control of the extreme values, whether null or negative.And a comparison of the class names present on either side.One important practical consequence follows for a bounding box project. The first control detects on its own four of the five errors listed above, a shifted or inverted box leaping to the eye at the first display, which makes this ten-minute verification more effective than any consistency check on the values.What the documentation must accompany
Five elements usefully accompany a delivered corpus.The name of the format effectively used as well as its version.The coordinate convention applied, by corners or by centre.The exact correspondence between numbers and class names.The precise meaning of each additional attribute.And the treatment adopted for images devoid of any object.One important observation follows for a bounding box project. The third element is often lost first, a correspondence between numbers and classes very often living in a configuration file separate from the corpus, which makes the dataset unusable as soon as that file disappears.What the corpus loses in changing format
Four pieces of information often disappear during a conversion.The attributes the destination format quite simply does not provide for.The distinction between an empty image and an unprocessed one.Decimal precision going beyond what the destination keeps.And the metadata proper to the project, such as author or date.One important practical consequence follows for a bounding box project. This loss follows a one-way street like that of the geometries, a rich format reducing without the slightest effort to a poor one and never the reverse, which invites keeping the original version rather than the converted one alone.What the format changes about daily work
Four effects make themselves felt during production.A single file locks as soon as several operators write to it.A file per image permits simultaneous work without the slightest conflict.Recovery after an incident is then limited to the single image concerned.And merging batches becomes trivial or else delicate depending on the format.One important observation follows for a bounding box project. The first effect is discovered in production rather than at scoping, a format designed for distributing a finished corpus suiting its manufacture by a whole team very badly, which leads many projects to produce in one format and deliver in another.Three errors proper to formats
Three bounding box defects belong to the file rather than to the drawing.A conversion delivered without ever having been displayed a single time.A format chosen without even knowing what the client’s chain expects.And a class correspondence kept entirely outside the corpus.Those three defects in no way alter an annotation taken in isolation, they reveal themselves when the corpus changes hands, and their common point is to bear on what surrounds the data rather than on the data itself.What the client must specify here
Four pieces of information come from the client rather than from the provider.The exact format they expect, its version included.The full class list with its numbering where one already exists.The attributes their chain can genuinely read and use.And the treatment they themselves give to images with no object.One important observation follows for a bounding box project. The second piece avoids a correspondence having to be established afterwards, a client who already holds a class numbering and does not pass it on forcing the provider to invent another, which produces an extra conversion and an occasion for error that nothing justified.What the format commits over time
Four effects show themselves long after delivery.A widely spread format is still perfectly readable years later.A proprietary format depends entirely on the tool that produced it.Documentation supplied alongside then survives the departure of its authors.And a class correspondence once lost renders the corpus mute.One important practical consequence follows for a bounding box project. The second effect deserves weighing at the moment of choice, a format closely tied to one particular tool staking the corpus’s readability on that tool’s survival alone, which shifts a technical decision towards a bet on duration.What the first batch must establish
Four results justify a format trial before production.The effective reading of the file by the client’s own chain.The correct display of all the boxes once converted.The preservation of the attributes throughout the conversion.And the treatment of images with no object at all, end to end.One important observation follows for a bounding box project. The first result is worth more than a declaration of compatibility, a file genuinely loaded by the client’s chain revealing within minutes requirements no documentation mentioned, which justifies passing ten annotated images around before producing ten thousand.What this subject has that is particular
Four traits distinguish this question from the course’s others.It depends neither on the care nor on the competence of the operators involved.It is settled by a plain convention rather than by a judgement.It nonetheless produces massive and perfectly silent errors.And it is verified in barely ten minutes once one thinks of it.One important observation follows for a bounding box project. Those four traits make it the simplest subject to handle and the most expensive to neglect, a verification that is nonetheless trivial avoiding on its own the loss of a whole corpus, which explains why this chapter is short and why its omission is regularly fatal.What the format changes about evaluation
Four points connect the format to quality measurement.Two corpora compared must share exactly the same coordinate convention.A systematic offset distorts every single overlap calculation.A different class numbering renders any comparison mute.And a badly encoded empty image then counts as a detection failure.One important practical consequence follows for a bounding box project. The second point produces a counter-intuitive effect, a perfectly correct model evaluated against a badly converted corpus showing poor performance without any defect being attributable to it, which sometimes leads to rejecting correct work on the strength of a false figure.What the annotation tool imposes here
Four constraints come from the tool rather than from the project.The native format in which the tool effectively records its work.The export formats it genuinely offers in practice.The fidelity of that export to the attributes actually entered.And the very possibility of reimporting what it has just exported.One important observation follows for a bounding box project. The last constraint is tested in five minutes and almost always neglected, a tool exporting a corpus it cannot then read back signalling a conversion that is approximate to say the least, which gives a simple means of assessing a tool’s soundness before entrusting a whole project to it.What merging several batches demands
Four points are checked before joining corpora produced separately.The same coordinate convention applied absolutely everywhere.A common class numbering rather than one local to each batch.Image identifiers staying unique across the whole set.And a size threshold rigorously identical from one batch to the next.One important practical consequence follows for a bounding box project. The second point causes the most silently faulty merge, two batches numbering their classes independently producing a corpus where the same value designates two different objects, which stays undetectable without comparing the correspondences side by side.What this chapter presupposes of the client’s chain
Four points stay the client’s responsibility once the corpus is handed over.The correct reading of the delivered format by their own tools.Scrupulous respect for the documented coordinate convention.Lasting preservation of the class correspondence file.And visual control after any later internal conversion.One important observation follows for a bounding box project. The last point escapes the provider entirely and sometimes ruins their work, a conversion conducted at the client’s without the slightest verification producing exactly the same silent errors, which justifies passing on the control method along with the data.What the provider brings here
Four contributions distinguish a serious bounding box delivery.The format required, obtained from the client well before production.A systematic visual verification after each conversion.The original version kept alongside the converted one.And documentation bearing on the convention applied as much as on the format.One important practical consequence follows. The third contribution costs only storage and regularly saves a project, a badly conducted conversion always being redoable from the original whereas a single faulty conversion requires redoing the annotation itself.Approaching the choice of a format
Five questions scope this choice on a bounding box project.What format does the client’s chain expect. It often decides.Are attributes needed. They rule out certain formats.Will the images be resized. Relative values withstand that.Is the corpus very large. The single file grows heavy.And is a conversion planned. It demands a control.Those five answers determine the genuinely useful format. Asking them before production avoids a late conversion as well as the errors it brings.The question that frames the choice
One question determines the useful format in bounding box work.Will the corpus serve one precise tool or several successive uses.One precise tool, a training chain already in place, imposes its format and makes any debate superfluous.Several uses justify the richest format, deriving from it afterwards the impoverished versions each tool requires.That question belongs to the corpus’s destination and not to the provider’s habits, it is asked before the first image, and it separates a planned conversion from an endured one.Three decisions before producing
Three decisions commit the format on a bounding box project.Asking the client the exact format expected by their processing chain.Checking that this format can effectively carry the attributes needed.And planning a systematic visual verification after any conversion.Those three decisions cost only a plain email, they precede the very first image, and their absence produces a late conversion whose errors will stay invisible.Three checks after a conversion
Three controls qualify a converted bounding box corpus.The display of the boxes across a dozen images taken entirely at random.The total object count, compared before and then after the operation.And the correspondence of class names verified on either side.Those three controls are conducted in barely ten minutes, they require no particular tool, and their absence lets through errors no file validation will ever flag.Three questions before delivering
Three questions precede any delivery of a corpus.Has the file genuinely been loaded by the chain awaiting it.Have the boxes indeed been displayed after the final conversion.And does the class correspondence effectively accompany the data.Those three questions are asked in a few minutes only, they precede any dispatch, and their absence turns a successful delivery into an incident the client will discover alone.What this chapter teaches
One cross-cutting observation deserves closing this examination.A format error produces a valid file and false data.Three findings compose it.A shifted box keeps perfectly plausible dimensions.A display across ten images detects four of the five common errors.And an empty image is poorly distinguished from an unprocessed one.That finding extends the preceding chapters, the invisible bearing here on the data rather than on the drawing.What this chapter shares with the previous ones
Three findings recur from the start of this course.A defect invisible in the deliverable reveals itself in use.Rich information degrades towards the poor and never the reverse.And an undocumented convention disappears with those who knew it.One important practical consequence follows for a bounding box project. The first finding takes its most mechanical form here, a conversion error producing entirely false data without producing the slightest signal, which shows that the defect’s invisibility belongs not to human judgement but to the very nature of this format.What this chapter leaves to the next
A file describes still images and says nothing about what links them.Three questions stay open in bounding box work.How to follow one same object from one frame to the next.What a constant identity adds as work and as value.And what to do with an object that disappears then reappears.Those three questions belong to video and tracking, which constitute the subject of the following chapter.Why this chapter is the cheapest one to act on
One point about where effort pays belongs at the close of this chapter.Every other chapter of this course asks for judgement, training or negotiation.Three reasons follow in bounding box work.Conventions of tightness or occlusion require agreeing with a client.Dense scenes require reorganising how the work is conducted.And geometry choices require measuring before recommending.One important practical consequence follows for a bounding box provider. This chapter asks for none of that, since displaying a dozen converted images requires no agreement, no training and no measurement, and a provider who cannot find ten minutes for it is unlikely to find the weeks the other chapters ask for.What a provider can offer at no cost here
Three things cost the provider nothing and change what the client holds.The class correspondence file, placed inside the corpus itself.A note stating which convention the coordinates follow.And the ten-minute check described here, passed on as a method.Those three items travel with the data rather than in an email, they survive the departure of whoever produced them, and their absence is what turns a good corpus into an unusable one two years later.Common mistakes
These failures recur often enough that naming them is usually enough to avoid them.- Converting a corpus without visually checking the result.
- Assuming a valid file holds correct data.
- Choosing a format without having planned for the attributes needed.
- Confusing relative coordinates with pixel coordinates.
- Ignoring the possible offset of class numbers.
- Omitting to distinguish an empty image from an unprocessed one.
- Discovering the format the client expects after production.
- Neglecting the count check before and after conversion.
- Encoding an attribute in the class for want of provided space.
- Documenting the format without documenting the convention applied.
