Comparing Ten Ways to Translate Text in an Image Without Changing the Design
This article compares ten ways to change the language of words that are already baked into a picture, while the layout, type treatment, and background are supposed to stay. It is a column-by-column comparison, not a question list, not a price sheet, and not a personal trial log. The ten rows are labels for ten different bargains. They are not a medal table, and a lower cost cell is not a higher fidelity cell.
Read the table first. Every later section is a reading of these cells, then a paired comparison of rows that people mix up, then three tutorials that sit on three of the rows.
| Method | Fidelity | OCR | Languages | Difficulty | Cost | Speed | Fit |
|---|---|---|---|---|---|---|---|
| 1. Manual design | Very high | N/A (human) | Any | High | Highest labor | Slow | Brand / print |
| 2. OCR + typesetting | High | High | Many | Medium-high | Low (open source) | Medium | Docs, diagrams |
| 3. Document service | High | High | Very many | Low | Medium-high fee | Fast | Bulk PDF |
| 4. Online AI | High | High | Many | Low | Low/medium (free allowance + paid) | Fast | Ecommerce, comics, menus |
| 5. Phone apps | Low | Medium-high | Many | Very low | Low (free) | Real-time | Reading only |
| 6. Multimodal model | High | High | Very many | Low | Medium-high (API) | Medium | Infographics, posters |
| 7. Diffusion editing | Medium-high | Medium (needs a mask) | Many | Medium | Medium | Medium | Creative work; style can shift |
| 8. Python pipeline | Medium | Medium | Many | High (coding) | Low (open source) | Flexible batch | Private automation |
| 9. Human + DTP | Very high | N/A (human) | Any | Very high | Highest fee | Very slow | Brand, legal, events |
| 10. Source file | Very high | High (from the source) | Many | Medium | Low if the software already exists | Medium | InDesign / source in hand |
How the Eight Columns Should Be Read
The header row is the whole argument. If a later paragraph seems to praise a row, check it against the cell. The direction of the table is fixed. Phone apps are the low cell in fidelity. Manual design and professional human-plus-DTP work are the high end of fidelity. Free, or nearly free, is not the strongest result on this table.
Fidelity means how closely the finished picture still looks like the original design after the words change. It does not mean how elegant the translation reads, and it does not mean a promise that every surrounding pixel is untouched. Very high is the top band: a person, or a live source file, can match weight, color, tracking, and effects. High is the next band: the layout is largely kept, with errors mainly where the new language does not fit the old box. Medium-high is a strong background repair with less reliable letterforms. Medium is a rough spatial match, often with a handmade font choice and a simple background fill. Low is a reading overlay. The low cell belongs to phone apps. Nothing elsewhere in the cost column reverses that.
OCR / recognition says who finds the words. N/A (human) means a person reads them. High means a structured recognizer, or the source file itself, usually returns the lines. Medium-high on a phone is good enough to understand a sign and not good enough to trust as a design extraction. Medium on a diffusion row means the model often needs a mask rather than discovering every line on its own. Medium on a script means the result depends on which detector you wired in. High (from the source) means the characters are still live text in a design file, so you are not guessing at pixels.
Languages is coverage, not a quality score. Any means a human can take a language the software was never sold as supporting. Many means a broad machine-translation set. Very many marks the document-service row and the multimodal row, where the catalog of languages is wide. Do not read Any as "more products" or as a higher score. It means the limit is the person, not a menu.
Difficulty is the operator's burden, not the hardness of the sentence. Very low is point a camera. Low is upload or write a prompt. Medium is prompt craft, or design software you already know. Medium-high is software plus judgment when line lengths move. High is a designer, or a programmer building a pipeline. Very high is an expert translation-and-desktop-publishing team. A low difficulty cell can still sit next to a high fidelity cell (online AI, document services, multimodal editing). A high difficulty cell can still sit next to a very high fidelity cell (manual design). Difficulty does not sort quality.
Cost on this table is qualitative. It names labor, a service fee, an API or subscription, an open-source stack, a free allowance plus paid credits, or software you already own. This comparison stays qualitative on money. It does not treat the lowest-cost cell as the row you should ship. The highest labor sits on manual design. The highest fee sits on professional human-plus-DTP. Low open-source money cost sits on OCR typesetting and on a custom script, and both still spend time. Low/medium on online AI means a free allowance for ordinary trials, then payment or credits when the work becomes a batch. That allowance is a capped trial, not an open-ended free pass. Phone apps are low cost and also the lowest fidelity. Read those two cells together.
Speed is the clock once the path is available, not the time required to learn a profession. Real-time is the phone, on the order of a few seconds, for reading. Fast is a document service or an online AI redraw, often seconds to a minute for a single picture, or a few minutes for a long PDF. Medium covers multimodal calls (seconds to tens of seconds, plus review), diffusion (about ten to tens of seconds), source-file edits, and the typesetting tail of an OCR workflow. Slow is manual design, minutes to hours. Very slow is the professional DTP engagement. Flexible batch on the script row means a single image can run in about a few seconds after the pipeline exists. The build is the expensive part of that row, and it is not in the speed cell.
Fit is who the row is for. It is not a trophy. Brand and print sit with manual design. Docs and diagrams sit with OCR plus typesetting. Bulk PDF sits with a document service. Ecommerce, comics, and menus sit with online AI. Reading only sits with the phone, and that word "only" is the point. Infographics and posters sit with multimodal editing. Creative work that can tolerate a style shift sits with diffusion. Private automation sits with a script. Brand, legal, and events sit with human plus DTP. InDesign, or any job where the source file is still in hand, sits on the last row. If your job is not in the fit cell, the rest of the row is the wrong bargain even when another column looks attractive.
Two reading traps show up constantly. The first is to scan the cost column, stop on "free" or "open source," and treat that row as the strongest way to protect a design. The fidelity column disagrees. The second is to treat method numbers as an ordered list from strongest to weakest. The numbers are only labels so the pairs below can point at a row. Method 4 is not a placement. Method 1 is not the answer in every column. It is the slow, high-labor, very high fidelity end.
The Four Constraints Those Columns Are Scoring
A translated document can reflow. Text baked into an image cannot. The box is a patch of pixels with a fixed width, a fixed height, and neighbors that are arrows, photos, or a product shot. Every row in the table is a different way of living with four constraints. The columns are scores against those constraints, not a single abstract grade.
Length moves, and the box does not. German and French usually run about 30% longer or more than the English they replace. Chinese and Japanese usually run shorter. The original design's cell does not grow to meet the new sentence. Someone, or some model, has to resize, rewrap, or retrack. A row that ignores length will either overflow the button, collide with a logo, or leave a sad empty band where the English used to sit. That is why even the high-fidelity machine rows still ask for a human check, and why the very high rows spend minutes to hours on a single layout.
Type has to match, not merely be legible. The original face, weight, color, letter-spacing, and effects such as a shadow or an outline are part of the design. A correct translation in a default sans-serif is a different poster. Rows that let a person pick the face (manual design, DTP, source-file editing) can chase that match, and they still fail when the identical font is not available. Rows that synthesize a look (online AI, multimodal models, diffusion) can come close on ordinary jobs and drift on a decorative face. Rows that stamp a system font (the phone, and a naive script) do not try.
The background under the old words has to be rebuilt. Erasing source text destroys the pixels underneath. A flat brand color is easy. A photo, a gradient, a fabric texture, or a highlight on packaging is not. Manual work reconstructs it with clones and patches. Diffusion and generative fill try to invent a continuation of the texture. A script often paints a flat color or a neighborhood average, which is why that row sits at medium fidelity. A phone often drops a coarse mask or a tinted slab over the region and calls the job done, which is why that row sits at low fidelity.
Non-text pieces carry meaning too. Arrows, callouts, numbering, and legends either contain words or point at words. Move a caption and forget the leader line, and the diagram lies. A clean comparison has to ask, for each row, whether those pieces are in scope. OCR-plus-typesetting, as usually practiced, does not handle them. A multimodal model is better at keeping visual relationships and still drops words. A human DTP pass can move the arrow and the number together. The fit column for diagrams is partly about this constraint, not only about how many text boxes exist.
Hold those four constraints next to the table and the pairs below stop looking like a software catalog. They are ten answers to the same question: who rebuilds the box, the face, the background, and the arrows, and what do they refuse to do?
Manual Design Beside Professional DTP
Rows 1 and 9 share the top of the fidelity column. Both say very high. Both use a person. Both are slow. They are not the same contract, and the cost column is careful about that: highest labor on row 1, highest fee on row 9. Neither cell means "a guaranteed untouched file." Both mean a skilled person can reproduce weight, color, position, and effects more closely than a model, and that the result still depends on skill and on whether the same font can be found.
What row 1 actually does
A designer works by hand in Photoshop, Illustrator, InDesign, GIMP, or Figma. Tesseract can help extract the source words. It does not set the type. The pipeline is extract, then translate and proofread, then find or recreate a matching font, then erase the original words, insert the translation, and rebuild effects. Input is any ordinary image, PNG or JPEG included. Output is a new image in the same format, or an editable PSD or AI file with layers, which is the one advantage this row has over a flattened export: the next language can start from layers if someone kept them.
Automation is low. Only the extraction stage is a candidate for a script. Accuracy sits in the highest band because the designer controls face, position, and style. It is also slow, and it is sensitive to the 30% expansion problem. Without the identical font, a complete alignment is hard. Minutes to hours is the honest clock, depending on how many boxes, how decorative the face, and how broken the background is. The software itself has a learning curve, so the row is a poor fit for volume even before the invoice. The fit cell says brand and print: ad posters, packaging, UI prototypes, and print collateral where a slightly foreign face would be obvious.
Atlas Cloud's observation belongs on this row. After OCR lifts the words, someone still has to place them back into the design. A pure image edit that merges the change onto a new raster layer gives less control over individual letters. Manual typesetting is the slower path and the more precise one. That is a comparison inside row 1, between "a designer sets real type" and "a raster patch pretends to be type." It is also why row 1 outranks row 8 on fidelity even when both end as a bitmap.
What this row will not do: it will not be the fast cell, and it will not be the cheap cell. It will not, by itself, keep terminology consistent across a hundred SKUs unless someone adds a glossary. That gap is why row 9 exists beside it rather than inside it.
What row 9 actually does
Row 9 outsources the same class of care to a translation-and-design team. A translator handles the words first. A desktop-publishing designer then replaces them against the original, step by step. The path is identify and edit the source (a PSD or an InDesign file when one exists), translate, adjust the layout, and re-render in the same software. The usual tools are the Adobe suite, InDesign, and Illustrator. Vendors often run the words through CAT tools such as Trados or MemoQ so terminology stays stable. The final picture still depends on the design software, not on the CAT tool. The CAT tool does not repaint a package.
Input can be any image or a real source file. Output is typically a high-quality localized image or an editable file. Automation is low. A person intervenes at every step, which is why difficulty is very high rather than merely high. Fidelity is very high, in the same top band as row 1, with an extra claim the design-only row does not make as clearly: the translator can adapt cultural nuance while the designer preserves or deliberately adjusts the layout. Time and cost are the highest on the table. The fee combines translation and design time and sits far above machine options. The clock is very slow. The fit cell is brand campaigns, major trade-show materials, image content inside government or legal documents, and publications that need a human proofreading pass.
How to tell the two rows apart
Use row 1 when a designer who can also shepherd the words is the whole team, and the artifact is a poster, a package, or a print piece. Use row 9 when the words themselves are legally or commercially sensitive, when terminology has to match a memory that already lives in Trados or MemoQ, and when you are paying for a separated translator plus a DTP operator rather than hoping one person covers both. Do not expect row 9 to be "more very high" than row 1. The fidelity column does not have a cell above very high. The difference is accountability, terminology, and who signs the proof, not a secret eleventh grade of visual match.
Do not send either row a job whose fit cell is "reading only," and do not send either row a batch of forty menu photos that must ship this afternoon. Those jobs are later rows. The comparison only works if the very high cells stay expensive and slow on purpose.
OCR Typesetting Beside a Document Service
Rows 2 and 3 both say high fidelity and high OCR. Both are for text that is structured: manuals, diagrams, reports, scanned pages. They split on who does the last mile of typesetting, and that split moves difficulty from medium-high to low, speed from medium to fast, and cost from low open source to a medium-high fee.
What row 2 actually does
The pipeline is OCR, then translation, then layout reconstruction, then an image. A recognizer returns each box's words and, if you ask it, the box's position. A machine engine or a human supplies the translation. Layout software or a script puts the new words back near the old coordinates, in a face you choose. Tools on the recognition side include Tesseract, EasyOCR, and Adobe Acrobat OCR. Tools on the translation side include Google Translate, DeepL, and Baidu Translate. Tools on the layout side include Adobe InDesign, Photoshop, and, in code, Pillow or Matplotlib. Input is PNG or JPEG, or a similar bitmap. A vector detour through PDF or AI can sit in the middle so the layout is not flattened too early. Output is a new image.
Automation is medium. Recognition and translation can run unattended. Final typesetting usually needs a person, especially when the target language is much longer or much shorter than the source and the font size or leading has to change. Fidelity is high when the faces and the frames match. It is not very high, because expansion still breaks the original spatial distribution, and because small errors in kerning and ligatures creep in. Positioning mistakes on a complex graphic hurt more than they do in a simple caption. The row also does not handle non-text elements. Leader lines and numbering stay manual. That limitation is why a diagram job on this row is never "OCR and walk away."
Time splits into two clocks, and the table's medium speed is the sum of them. OCR plus translation takes seconds to minutes. The typesetting that follows takes minutes to tens of minutes. Money cost is low if you stay on open-source recognizers and a layout tool you already have. The fit cell is chart annotations, technical manuals, and educational diagrams with many text elements.
The background logic is the same logic PDF translators use. They parse structure, translate region by region, and replace text in place so the layout survives. Run OCR and block-by-block translation on an image and you are doing that job without a real text layer. Row 2 admits the missing text layer. Row 3 tries to rent one.
What row 3 actually does
A format-preserving document service parses layout and fonts, machine-translates each block, and re-typesets the output. The steps are layout parsing (text-box coordinates and fonts), text translation through a cloud service or a local engine, layout re-rendering, and an output file. Pictures in the document are typically left untouched, which matters for manuals: you want the diagram's photograph stable while the captions move.
Named tools in this row include PDFTranslator, which uses Gemini and ChatGPT engines, the Pangeanic ECO platform, Pairaphrase, and Smartcat. Many of them accept a PDF or an image and return a translated PDF or a graphic that keeps the original styling. Input is a scan, an image, or a PDF (JPG, PNG, or PDF). Output is a translated file in the same general format, with layout, tables, and graphic positions essentially intact.
Automation is high. The system runs end to end. A person still proofreads, lightly. Fidelity is high. Advanced services pair a high-precision OCR step with dedicated translation systems and aim at coordinate-level mapping of text and format. Document-level fidelity can reach 90%+. The errors that remain come mostly from translation length, not from a failure to see the page. Handwriting and odd layouts are a weak spot. Do not read 90%+ as "a photographed poster with a script logo will match a DTP file," and do not read it as very high. The cell says high. A 60-page PDF is on the order of a few minutes, which is why speed says fast. The work is a paid service or an API quota. Bulk and long documents cost money. Difficulty for the operator is low, because the product is turnkey. The fit cell is enterprise multilingual technical documents, product manuals, training materials, and financial reports where the layout has to stay faithful. Under the hood this row is still OCR plus translation plus automatic typesetting. The difference from row 2 is that the typesetting is inside the service.
How to tell the two rows apart
Choose row 2 when you want the open-source cost cell, you can spend minutes to tens of minutes setting type, and the artifact is a diagram or a manual you are willing to touch. Choose row 3 when the pile is a bulk PDF, you want the fast cell, and a medium-high fee is acceptable in exchange for not operating InDesign yourself. Both stay in the high fidelity band. If the scan is handwriting, or the layout is a collage rather than a document, neither row's OCR cell saves you. That is a shared limit, not a reason to jump to the phone.
If the file is already a live InDesign document, you are not on row 2 or row 3 yet. You are on row 10, and dropping back to OCR is what you do only after someone has flattened the art.
Online AI Redraw Beside a Phone Camera Overlay
Rows 4 and 5 are the pair most often collapsed into "just use an app." The speed column invites that mistake. Both are fast. Both cover many languages. Both can start from a photo with no source file. The fidelity column refuses the collapse. Row 4 is high. Row 5 is low, and it is the lowest fidelity on the table. One of them redraws words into the picture. The other helps a person read.
What row 4 actually does
An online AI tool built for images detects text regions, translates them, erases the original strokes, and repaints the translation in a similar face, color, and size. The practical sequence is upload, automatic OCR of the regions, an automatic translation you are allowed to proofread, a model pass that removes the old words and draws the new ones, and a download. OCR, machine translation, and image completion are bundled into one generate action. You do not need the layered design file, a local install, or a design credential.
Tools named on this row include ReWords AI, ImageGPT, EditTextImage, Codia, and VisualGPT. Interfaces in this category often let you lock a line that must not change, such as a brand name, and edit the suggested translation before anything is painted. To translate text in an image on this row, the operator uploads a bitmap and works line by line rather than hoping a single prompt remembers every box. Input is a normal PNG or JPEG. Output is a bitmap at the same resolution, with the translation rendered in the original style as far as the model managed it.
Automation is high. Difficulty is low. Fidelity is high, not very high. Modern generative models match ordinary font style and background texture well enough that a casual glance does not see an edit. Very dense text, complex lighting, and highly decorative fonts still produce flaws. OCR quality follows the source image. The translation is largely neural, so quality varies and a human review is part of the row, not an optional extra. The high cell is not a promise that every surrounding dot of the original art survives.
Time is seconds to a minute for a typical image. Cost is low/medium: a free allowance is common, and bulk work requires payment or credits. ReWords AI, as one tool in this category, includes a few free generations per image, then paid credits. That is a limited allowance, then paid credits. It is not an open-ended free pass. Copyright and sensitive content still need a human decision before upload. The model is not a confidentiality policy.
Two examples fix what "high, and not a reprint of the design file" looks like. ReWords AI shows packaging where SUMMER SALE is replaced with 夏季特卖 while the background stays in place. EditTextImage shows the banner line "Summer sale — 30% off everything" replaced with the German "Sommer-Sale — 30 % auf alles" with the layout kept. German expansion is exactly the 30% problem. A successful result on that banner means the line was re-fitted, not that the English box was magically wider. The fit cell is everyday localization: ecommerce product images, ads, social graphics, menus, flyers, and comics, especially when the original file is gone.
What row 5 actually does
A phone camera translator takes a photo or an imported image, recognizes the text, and either overlays a translation on the screen or saves a snapshot with the new words stamped on. The flow is capture or import, automatic OCR, automatic translation, overlay or mark, and a look at the result. Tools include the Google Translate app, Baidu Translate's camera mode, Microsoft Translator, and WeChat's built-in scan-translate. Input is a phone photo or a screenshot. Output is usually an overlay or a block of translated text. Some apps save an annotated image.
Automation is complete. Difficulty is very low. You type nothing. Fidelity is low. The goal is comprehension. The translation uses a default font and a coarse background mask, and the original layout and style are not preserved. Recognition and translation quality can be close to professional engines. The picture still is not a file you publish. People who photograph text with Baidu Translate and save the image often see the tool's brand mark, or a patch covering part of the photo. A watermark or a mask is a normal outcome on this row, not a surprise defect.
Time is a few seconds, which the table calls real-time. Cost is low and often free. The fit cell says reading only: foreign menus, street signs, and manuals while traveling or in daily life. The moment the same menu has to be posted as the restaurant's own picture, this row is the wrong cell. Fast and free did not make it the strongest design path. It made it the reading path.
How to tell the two rows apart
If the output has to replace the original asset in a store, a feed, or a print PDF, start on row 4 or higher, not on row 5. If a traveler needs to know what a sign says, row 5 is the fit, and judging it for failing to match a typeface is a misread of the fidelity cell. Row 4's free allowance does not promote it into the very high band beside manual design. It promotes a trial. Dense type, a glare, or a script logo still goes back for a retry, a locked line, or a human row.
The lock control is the practical difference in authority. Row 4 can keep a brand name in the source language while the slogan moves. Row 5 will often translate the brand name too, or cover it. That single behavior is enough to keep the rows apart even before you look at fonts.
Multimodal Editing Beside Diffusion Inpainting
Rows 6 and 7 both ask a generative model to produce a new picture. Both can touch the summer-sale class of job. They are not the same fidelity, and they do not demand the same preparation. Row 6 is high fidelity, high recognition, very many languages, low difficulty, medium-high API cost, medium speed. Row 7 is medium-high fidelity, medium recognition because it needs a mask, many languages, medium difficulty, medium cost, medium speed. The fit cells diverge: infographics and posters on one side, creative work that can accept a style shift on the other.
What row 6 actually does
A multimodal model takes the original image plus a natural-language instruction such as "translate the text and keep the design." It combines detection, semantic understanding, and image generation. The flow is image plus instruction, recognition and translation inside the model, a new image, then a human proof. Tools include ChatGPT with image features such as GPT-4V, the DALL·E 3 image-editing API, and Google Imagen Editor, which is mostly at a research stage. Developer access runs through the relevant API. DALL·E as an editing family sits here when the interface is an instruction over an image, and it sits again on row 7 when the interface is a mask plus a fill. The row is the pattern, not the logo.
Input is an image plus a prompt. Output is a new image, usually at the original resolution or at a size you specify. Automation is high. A prompt is enough to start, which is why difficulty says low, even though writing a careful prompt is a skill. Fidelity is generally high. These models keep layout relationships and style well on marketing art. Published examples include a coffee-machine instruction diagram translated into Spanish with the layout kept, and Atlas Cloud's report of GPT-4V translating infographic text into other languages while leaving the rest of the graphic intact. They also miss lines, misspell words, leave a fragment untranslated, or shift the composition when the new copy is much longer or shorter than the old copy. Follow-up fixes are normal. This row does not replace fine typesetting. It does well on a large share of marketing scenes, which is a fit statement, not a claim that the very high band is obsolete.
Time for one image is seconds to tens of seconds, plus the time you spend on the prompt and on the review. Cost is medium-high because advanced models are server calls with an API or subscription cost. The fit cell is infographics, posters, illustrated promotional material, and UI screenshots where you want the model to reason about what must stay. A workable instruction shape is: translate all the text into Chinese, and do not change anything else. The model then attempts a full-image result rather than a single masked box.
What row 7 actually does
Diffusion editing masks the text region and generates a replacement from a prompt. The flow is detect text and build a mask, write a prompt on the order of "replace X with Y and keep the background," fill with DALL·E 3 or Stable Diffusion inpainting, and take the new image. You might upload the original and a text mask to an API and request an edit that replaces the text. Tools include the DALL·E 3 editing API, Adobe Firefly with Generative Fill, and HuggingFace Diffusers, including weights such as runwayml/stable-diffusion-inpainting. ControlNet's text-related controls and LaMa inpainting help mark what should be replaced and what should be rebuilt. The mask can be drawn by hand or generated by a detector. That extra step is why automation is medium-high rather than high, and why difficulty is medium: prompt craft plus a mask, not a single sentence.
Input is the original, a text mask, and a prompt. Output is an image file. The model is asked to match language and style. It does not always do so. Fidelity is medium-high, a step under dedicated text-editing models and under the high cell of row 6. Diffusion is often imprecise on long text and can break words in the middle. Style consistency depends on the prompt. The strength is background repair. A translation can blend into a complex texture more naturally than a flat fill. The weakness is letterforms: imperfect shapes, a slight blur, or an extra detail the prompt did not request. Tuned masks and tuned prompts are how this row reaches the top of its own cell. It does not climb into very high by tuning alone.
One image typically takes about ten to tens of seconds, longer if a cloud queue is involved, or however long a local GPU needs. Cost is medium: API or compute, not the highest labor and not a free phone. The fit cell is creative translation, concept art, slogans inside illustrations, and any job where a slight style shift is acceptable. The banner example on this row is Stable Diffusion taking the same English line, "Summer sale — 30% off everything," and re-rendering the German "Sommer-Sale — 30 % auf alles," with the background kept and the letters regenerated. Long copy is where word-breaking shows up. A three-word slogan hides the weakness. A paragraph on a poster exposes it.
How to tell the two rows apart
Use row 6 when you want the model to find the words, when the artifact is an infographic or a poster with arrows and a hierarchy, and when an API cost in the medium-high band is acceptable. Use row 7 when you already know the region, you care more about texture continuity than about perfect glyphs, and a style shift is allowed. If the letters themselves are the brand, neither row replaces row 1 or row 9. If the letters are long, row 7's medium recognition and broken-word habit are the risk you are accepting in exchange for a more natural hole-fill.
Do not describe either row as a conversion that leaves every surrounding dot untouched. Both synthesize pixels. A proof pass for spelling, numbers, and leftover source-language fragments is part of the speed you actually experience, even though the generation clock is seconds to tens of seconds.
A Custom Script Beside an Editable Source File
Rows 8 and 10 are what teams mean when they talk about automating the job, or about still having the file. One builds a bitmap pipeline. The other edits live type. Their fidelity cells are not neighbors. Medium versus very high. Their cost cells look similar only if you ignore what "low" refers to: open-source libraries on row 8, software you already license on row 10.
What row 8 actually does
A self-built pipeline detects text regions with computer vision, translates them, and draws the result back onto the image. Detection might be OpenCV edge or contour finding, or a deep OCR model. Translation is an API. Drawing is Pillow or OpenCV. The steps are detect, OCR and translate per box, cut out the region and fill the background with an inpainting routine, draw the new text, and write the file. The tool list is Python, Pillow, OpenCV, EasyOCR, pytesseract, and a translation API such as Baidu or Google. Adobe PixelSense is part of the same custom-imaging conversation, as are C# and .NET image-processing stacks. There is no requirement for an off-the-shelf GUI. Input is a normal bitmap. Output is a bitmap at the same resolution.
Automation is high if the script is actually finished. Batch is the point. Difficulty is high because someone has to code, debug fonts, and decide what "fill the hole" means. Money cost is low relative to a third-party service, because the libraries are open source. Development cost is high, and that cost is time and salary, which the table records as high coding difficulty rather than as a fee cell. Runtime, once the script works, is about a few seconds per image. That is the flexible-batch speed cell. It is not "a few seconds from a standing start on Monday."
Fidelity is medium. The layout can be roughly matched. Fonts are usually not matched automatically. A person picks the nearest face. Background repair is usually worse than a diffusion model. The common fills are a flat color or a neighborhood average. Complex backgrounds and non-standard fonts are where the row gives up. Full control, and a path that need not call a public network, are the real advantages. Design-detail fidelity trails dedicated AI tools and needs parameter tuning plus a correction pass. The fit cell is an enterprise process with special constraints, a privacy requirement, or small-scale label replacement, such as a merchant scripting OCR, translation, and write-back for product-image labels.
What row 10 actually does
If the picture was exported from vector or design software, the clean comparison is to stop treating it as a picture. InDesign or Illustrator, with plugins or scripts, can extract text, translate it, and put it back into text frames. Another route converts the image to PDF, runs an OCR translation, and imports the result back. Tools include Adobe Acrobat (OCR and export to Word), Illustrator's find-and-replace on text, InDesign scripts, and third-party plugins such as Lokalise or Transifex's InDesign plugin. Input is usually an editable document or a PDF. Output is the original file with the text replaced, which means layers and effects are still real.
Automation is medium. It depends on how far the host software's scripting goes. Fidelity is very high, in the top band, because you are editing the source rather than inventing pixels, provided that source exists. If the art has already been flattened, this row collapses. You need OCR help, and the behavior becomes row 2. Time is medium. Automated replacement still needs a human to fix line breaks, overflows, and style overrides. Cost is low if the software is already in the building. Difficulty is medium: design software, not a new research project, and not a camera shutter. Languages are many. Recognition is high because it comes from the source, not from a guess about antialiased edges.
The fit cell is any project that still holds the design source, such as a manual laid out in InDesign, and the emergency case where a rough OCR translation is refined afterward inside that source file. "Afterward" is the important word. A rough OCR pass is not row 10. The refinement in the live file is row 10.
How to tell the two rows apart
Pick row 8 when there is no file, the volume is real, the pictures are simple enough that a flat or averaged fill will not embarrass the brand, and the work has to stay on machines you control. Pick row 10 the moment someone can produce the InDesign, Illustrator, or layered Photoshop document. It is the cleanest path on the table when that condition is true, not because the speed cell says so (it says medium) but because fidelity stays very high without a repaint. The moment the only artifact is an exported JPEG, stop describing the job as row 10. You have been moved to row 2, or to row 4 if you would rather repaint than retype.
Row 8's few-seconds runtime and row 4's seconds-to-a-minute runtime can look alike on a stopwatch. The fidelity cells do not. A script that paints a white or averaged rectangle is medium. An online model that rebuilds texture and a face-like treatment is high. Paying the coding cost of row 8 to imitate row 4 only makes sense when privacy, batch rules, or integration force you off a hosted tool.
What the Columns Agree On, and Where They Split
Read down the fidelity column in the order the cells actually use, not in the order of the method numbers. Very high: manual design, human plus DTP, and source-file editing when the file is real. High: OCR plus typesetting, document services, online AI, and multimodal editing. Medium-high: diffusion. Medium: a custom Python pipeline. Low: phone apps. That order is the table. Human design and professional DTP are the high end. The phone is the low end. Source-file work joins the high end only while the file survives. Online AI does not get promoted because it is fast or because a free allowance exists.
Read down the speed column and refuse the idea that faster is a substitute grade. Real-time is the lowest fidelity. Fast (document service, online AI) is the high band, not the very high band. Medium covers most of the remaining machine and source-file work. Slow and very slow are the two human rows that also own the top fidelity band. The script's flexible batch is a medium-fidelity speed, available after a high coding investment. A comparison that sorts only by speed will publish phone overlays and call them localization.
Read down cost and keep the qualitative labels. Highest labor and highest fee buy the top fidelity band and the slow clocks. Medium-high fees buy document services and multimodal APIs, both high fidelity, one fast and one medium. Medium cost buys diffusion at medium-high fidelity. Low/medium buys online AI at high fidelity, with a free allowance that ends when the batch starts. Low open source buys either high fidelity with a typesetting tail (row 2) or medium fidelity with a code base (row 8). Low free buys the reading overlay. There is no column in which "free" and "very high fidelity" occupy the same row.
A few splits are sharp enough to memorize.
- Recognition is N/A on the two human rows because a person is the recognizer. It is high on rows 2, 3, 4, 6, and 10. It drops to medium where a mask or a homemade detector is doing the finding (rows 7 and 8), and to medium-high on the phone, where finding the words is good and keeping the design is not.
- Languages marked Any are the human rows. Languages marked Very many are the document service and the multimodal model. The other machine rows say Many. A rare language is a reason to look at rows 1 and 9, not a reason to claim a phone speaks everything.
- Difficulty is very low only on the phone, low on the turnkey machine rows (document service, online AI, multimodal), medium on diffusion and on source files, medium-high on OCR typesetting, high on manual design and on coding, and very high on the DTP team. Low difficulty plus high fidelity is a real combination. It is rows 3, 4, and 6. It is not a reason to skip proofreading.
- Fit is the column that stops a "good" row from being used on the wrong object. Brand and print, or brand and legal and events, stay on rows 1 and 9. Bulk PDF stays on row 3. Diagrams stay on row 2 unless the source file pulls them onto row 10. Ecommerce, comics, and menus are the online AI fit. Reading stays on the phone. Infographics lean multimodal. Creative pieces that can shift style lean diffusion. Private batch leans script.
Where the columns agree: no row is high fidelity and real-time and highest-labor at once. The constraints in the previous section, length and background especially, are why. A few seconds is enough to overlay a translation or to ask a model for a redraw. It is not enough for a person to rebuild a package face and a legal line of type. Agreement number two: every machine row can be wrong about a number, a unit, or a proper noun. The table's fidelity cells do not measure that. A high visual cell can still say the wrong price. That is why the tutorials below all end in a proof, and why row 4's lock control and row 9's CAT tools are part of the comparison rather than extra tips.
Three Tutorials Mapped to Three Rows
The three tutorials are worked paths for rows you have already compared. Tutorial 1 is an edit call with a mask and an instruction, so it sits on the multimodal row and borrows the mask habit of the diffusion row. Tutorial 2 is the online AI row, with no local install and no mask file. Tutorial 3 is the Python row, Spanish in and English out, with a rectangle painted over the old words. None of them is a new eleventh method. None of them moves a fidelity cell.
Tutorial 1: A masked edit on the multimodal row
The job is the English phrase "Summer sale" translated to the Chinese 夏季特卖. Preparation is an API key from the provider, a sample image, and a mask that covers only those words. The flow is the original image in, a call to a GPT-4V or DALL·E editing endpoint, recognition and translation by the model, a generated image, then a download and a proof. This is row 6's instruction style welded to row 7's mask. Expect the fidelity discussion from those two rows, not the very high cell from row 1.
Prepare orig.png and mask.png so they share the same dimensions and the same origin. The mask should cover the "Summer sale" region and nothing else. If the mask spills onto a logo or a price that must stay in English, the model has permission to repaint those pixels too. That is a mask error, not a mysterious model mood.
The call, using the OpenAI Python SDK shape as the example:
import openai
openai.api_key = "YOUR_API_KEY"
# Ask the model to translate the text in the masked area into Chinese
# while leaving everything else unchanged.
response = openai.Image.create_edit(
image=open("orig.png", "rb"),
mask=open("mask.png", "rb"),
prompt="用中文翻译上面的文字,不改变其他内容。",
n=1,
size="1024x768"
)
# Save the returned image to disk
with open("output.png", "wb") as f:
f.write(response['data'][0]['image'])
Read the call against the columns. The prompt asks for a Chinese translation of the text in the masked area and tells the model to leave other content alone. n=1 asks for a single generation. size sets the requested output size at 1024 by 768, which may or may not be the original artwork's size. If the source banner is a different aspect, this parameter is a place the layout can drift even when the prompt says not to change anything else. The key in the snippet is a placeholder, not a real credential. The last lines write the returned image to output.png.
Review output.png for the actual substitution. The intended result is 夏季特卖 in a similar face, on a background that still matches the surroundings. Then look for the failure modes that put this tutorial on rows 6 and 7 rather than on row 9: a missed word, a misspelling, a line that is much longer than the mask, a fragment of English still visible at the edge. If something is missing, tighten the prompt or translate smaller blocks instead of the whole poster in one mask. The API bills by image size and by the number of generations. That is a cost-structure fact, not a price list. Saving the file is not the last step. Optional position and style fixes in an image editor are how you climb toward row 1 after the model has done the first pass, and those fixes are no longer this tutorial.
Compared with tutorial 2, you own the mask and the key, and you accept an API clock of seconds to tens of seconds plus review. Compared with tutorial 3, you are not painting a flat rectangle yourself. The model is inventing the fill. That is why a good result can land in the high or medium-high band, and why a bad mask can damage regions you meant to keep.
Tutorial 2: The online AI row, without a mask file
This tutorial is row 4. The example tool is ReWords AI. The same sequence describes the category, including EditTextImage and the other names already placed on that row. Preparation is a browser. There is no install and no mask PNG.
The flow is upload, system OCR and detection, an automatic translation shown as suggested text, your edits and locks, an AI render, and a download. Open a tool made to edit text in an image and choose the translate-text function. Upload the picture. The worked example is an ad that contains SUMMER SALE.
Choose the target language, Chinese in this example. The platform lists the lines it found. Correct mistranslations before you generate. Lock any string that must stay, especially brand names. Then generate or apply. The model removes the original strokes and redraws the translation using the original font, color, and background as far as it can. Download the result. In the packaging example, the source side reads SUMMER SALE and the generated side reads 夏季特卖, with the background still in place.
The cost cell shows up here as an allowance, not as a blank check. These tools usually include a free allowance. ReWords AI includes several free generations per image. Beyond that, the work is payment or credits. Do not describe the allowance as an open-ended free pass. Do not describe a clean packaging result as a promise that every surrounding dot survives. Verify the text, especially numbers and proper nouns, because visual fidelity and factual fidelity are different columns, and only one of them is on the table. This path is the one to use when the design file cannot be recovered and the picture itself has to be localized. It is not the path for a brand-critical print file that the fit column assigns to rows 1 and 9, and it is not the path for a travel snapshot that only needs to be understood.
Set beside tutorial 1, there is no API key and no hand-drawn mask. The lock button is the control the masked prompt only approximates with words. Set beside tutorial 3, the background is a model rebuild rather than a white bar, which is why this row's fidelity cell is high and the script row's cell is medium. Set beside the phone, the output is meant to be an asset, not an overlay with a watermark.
Tutorial 3: The script row, Spanish recognized and English drawn back
This tutorial is row 8. A script extracts text, translates it, and draws it back. The stack is Tesseract OCR with OpenCV and Pillow. The sample direction is Spanish into English, which is the reverse of the Chinese and German marketing examples above, and that is useful. The columns do not depend on which way the language pair points. They depend on who rebuilds the pixels.
The flow is load, detect and OCR with Tesseract, call a translation engine, clear the old region, draw the new words with Pillow, and save. Install the system recognizer and the Python libraries first.
# Install Tesseract (example for Ubuntu)
sudo apt-get install tesseract-ocr
# Install Python libraries
pip install pytesseract pillow googletrans==4.0.0-rc1
The install comment names Ubuntu as the example. A different operating system changes the package command, not the pipeline. The library pin on googletrans is the version this example was written against. Pillow does the drawing. pytesseract talks to the Tesseract binary you just installed. If the Spanish language data is not installed, lang='spa' will not become correct English by wish. Recognition fails first, and the translation step only translates the failure.
from PIL import Image, ImageDraw, ImageFont
import pytesseract
from googletrans import Translator
# Load the original image
image = Image.open("image_with_text.png")
# Run OCR (recognize Spanish text)
text = pytesseract.image_to_string(image, lang='spa')
print("Recognized text:", text)
# Translate the text
translator = Translator()
result = translator.translate(text, src='es', dest='en')
print("Translation:", result.text)
# For this example the text position is known; in production you would
# use pytesseract.image_to_boxes to get a box per character.
x, y, w, h = 50, 50, 300, 50 # example coordinates
# Erase the original text on the image
draw = ImageDraw.Draw(image)
draw.rectangle(((x, y), (x + w, y + h)), fill="white") # cover with white
# Draw the translated text
font = ImageFont.truetype("arial.ttf", size=36)
draw.text((x, y), result.text, font=font, fill="black")
# Save the output
image.save("translated_image.png")
Walk the script in the same order the fidelity cell cares about. The image opens from image_with_text.png. Tesseract runs with lang='spa', so the recognizer is told the source is Spanish. The print is there so you can see the recognition before you trust it. Google Translate, through the googletrans library, takes src='es' and dest='en'. A second print shows the translation before any pixels change. Those two prints are the proof point row 8 often skips when someone only looks at the output file.
The position in this example is known in advance. The comment says so, and it names the production alternative: pytesseract.image_to_boxes for a box per character. The numbers are the example coordinates x, y, w, h = 50, 50, 300, 50. They are not a universal text location. A box that is 300 by 50 pixels starting at (50, 50) will cover the sample and will miss, or smash, any other layout. The erase step draws a white rectangle over that box. White is a flat fill. On a white slide it disappears. On a photograph it becomes a blank label, which is the neighborhood-average problem in its simplest form and the reason this row does not share row 7's background strength. The new words are drawn in Arial at 36 pixels, black, at the same origin. Arial is a stand-in face, not a recovered brand face. That single choice is why the row says fonts are picked by hand and fidelity stays medium. The save writes translated_image.png.
Running the script replaces that one region with the English translation. A real job would take regions from the OCR boxes, measure string width in Pillow, wrap when the German-or-French-style expansion (or any long English gloss of a short Spanish line) exceeds 300 pixels, and loop over lines. OpenCV contours can tighten the cut-out beyond a hardcoded rectangle. The whole script can be batched, which is the flexible speed cell. Layout fidelity still trails AI-inpainting methods. Test, and expect to tune. None of those improvements move the row to very high. They make a medium-fidelity pipeline less accidental.
Compared with row 2, this tutorial stops at a rectangle and a system font. Row 2's typesetting tail, the minutes to tens of minutes in InDesign or Photoshop, is exactly the work this script does not do. Compared with row 4, there is no learned fill and no lock button. Compared with row 10, nothing here is a live text frame. If you later obtain the InDesign file, you leave this tutorial.
Choosing from the Fit Column
The decision is three questions, answered by the fit column rather than by a single preferred row. How faithful must the picture be. What are you allowed to spend in labor, fees, or engineering time. Do you still hold the source file.
You have no source file, and you want the result soon. That is the common case. Use an online AI tool, row 4. Translate the text already inside an image, pick the language, correct the lines, lock what must stay, generate, and download. Expect high fidelity, seconds to a minute, and a free allowance that becomes paid or credit-based when the batch grows. Do not expect the very high band.
The image is text-heavy and structured: charts, manuals, diagrams. Use OCR plus typesetting, row 2, and plan for the typesetting clock of minutes to tens of minutes. If the same job is a bulk PDF or a pile of scans, use a format-preserving document service, row 3, and plan for a medium-high fee, a fast clock, and document-level fidelity that can reach 90%+, with handwriting and strange layouts left as the weak cases.
The result has to be print-ready and brand-critical. Use manual design, row 1, or professional human plus DTP, row 9. Both are very high fidelity. Row 1 is highest labor and slow, minutes to hours, and it is hard to align fully without the same font. Row 9 is the highest fee and very slow, with translators and DTP on the Adobe suite and terminology in tools such as Trados or MemoQ. Neither is the everyday menu path.
You want the work inside your own automated workflow. Use a multimodal model API, row 6, or a custom Python pipeline, row 8. Row 6 is high fidelity, very many languages, medium-high API cost, seconds to tens of seconds, with misses and length problems sent back for repair. Row 8 is medium fidelity, low open-source money cost, high coding difficulty, about a few seconds per image once built, and a background that is often a flat color or a neighborhood average.
You only need to understand a snapshot. Use a phone camera app, row 5. A few seconds, low fidelity, possibly a watermark or a mask, Google Translate or Baidu Translate or Microsoft Translator or WeChat. Never the publish path.
You still hold the editable source. Edit it directly, row 10. That is the cleanest path when it is available. Very high fidelity, medium difficulty, medium speed, low cost if the software already exists. If someone has already flattened the art, you are back on row 2.
A second pass through those six branches catches the crossings the table does not allow. Do not publish row 5. Do not quote row 3's 90%+ on a handwritten note. Do not quote row 4's allowance as an open-ended free pass, or its high cell as a promise that every surrounding dot survives. Do not build row 8 and then describe the white rectangle as equivalent to Generative Fill. Do not run row 10 vocabulary on a JPEG. Do not send a trade-show wall and a legal caption to a one-minute tool merely because the speed cell is attractive. The fit column already said brand, legal, and events.
Five Checks That Apply on Every Row
Whichever row the fit column selects, five checks decide whether the result is a localized design or only a translated string sitting on top of one.
Plan for the length change before you trust the box. German and French usually expand by about 30% or more. Chinese and Japanese usually contract. Resize, rewrap, or retrack. Never assume the translation fits the original rectangle. On row 4 and row 6 the model may reflow without telling you, and the proof is whether a neighboring logo was hit. On row 7 a longer line is where words break. On row 8 the 300-pixel example box will overflow in silence unless you measure the string. On rows 1, 9, and 10 a person sees the overflow and spends the slow clock on it. The check is the same. Only the labor changes.
Match the face, not only the dictionary. Reproduce weight, color, letter-spacing, and any stroke or shadow. A right translation in the wrong face still reads as the wrong design. Row 1 states the limit honestly: without the identical font, full alignment is hard. Row 8 states the shortcut honestly: Arial at 36 is a demonstration, not a brand match. Row 5 does not attempt the match, which is allowed only because the fit cell is reading. Rows 4, 6, and 7 attempt a likeness and still need a zoomed look at joints, accents, and punctuation such as the spaced percent sign in "Sommer-Sale — 30 % auf alles."
Rebuild the background so the patch is hard to see. The area behind the new words should meet its surroundings. Feather the edge and inspect the seam at a 1:1 view. This is row 7's strength and row 8's weakness, and it is the reason a white rectangle in the third tutorial is instructive rather than finished. Row 5's coarse mask fails this check on purpose. If your fit cell requires a publishable file, a failed seam sends you up the fidelity column, not to a second phone photo.
Account for everything that is not a sentence. Arrows, callouts, numbering, and legends contain words or point at them. Row 2 will leave leader lines behind unless you add a manual pass. Row 6 is better at keeping the visual relationship and can still skip a label. Row 9 can move the number and the arrow together because a person is responsible for both. A comparison that only scores the headline will ship a diagram whose step 3 now points at step 1.
Proofread the words as words. Machine translation is fast and imperfect. Numbers, units, brand names, and proper nouns need a person before publication. Row 4's lock is the mechanical version of this check. Row 9's Trados or MemoQ memory is the terminology version. The two print statements in the Python tutorial are the script version: read the recognition, read the translation, then paint. A high fidelity cell does not absolve a wrong digit. The table never claimed it did.
What This Comparison Does Not Claim
The table does not name one row for every job. It names ten bargains. Manual design and professional DTP sit at the high end of fidelity, and they sit at the high end of time and of labor or fees. Phone apps sit at the low end of fidelity, and they sit at the convenient end of speed and cost, for reading only. Online AI sits in the high band, on a fast clock, with a free allowance plus paid or credit-based use after that, for ecommerce images, comics, menus, and the other everyday files that no longer have a layered original. That is the common-case fit. It is not a promotion into the very high band, and it is not a license to skip the five checks.
Document services stay the bulk-PDF answer, at high fidelity that can reach 90%+ at document level, in about a few minutes for a 60-page PDF, on a paid or quota basis, and they stay weak on handwriting and odd layouts. Multimodal models stay the infographic answer, high fidelity, seconds to tens of seconds, with coffee-machine diagrams and infographic text as the kind of job they are shown on, and with misses and length gaps sent back. Diffusion stays the texture answer, medium-high, about ten to tens of seconds, willing to break long words. A Python pipeline stays the private-batch answer, medium fidelity, a few seconds a picture after the code exists, with flat or averaged fills. A living source file stays the clean answer, very high, and it falls back to OCR typesetting the day the file is flattened.
No row here is a conversion that leaves every surrounding dot untouched. No row owes you that kind of promise. No free allowance runs without a cap. A method number is only a label. Take the fit cell that matches the file you actually hold, read the fidelity cell next to it so you know what you are refusing, and proof the words before the picture ships.
评论
发表评论