Een vriend stuurde me een telefoonfoto en een screenshot en vroeg om hen in één afbeelding voor een vermelding. Ik liet beide in een canvas op hun eigen formaten vallen en kreeg iets dat niemand zou accepteren: een 4032 bij 3024 foto met een smalle 1170 bij 2532 screenshot ernaast, een band van leeg wit onder de screenshot en het hele ding 5202 pixels breed. De foto's waren prima. De regeling was het probleem en het is elke keer hetzelfde probleem, omdat de twee bestanden bijna nooit een dimensie delen. Beslissen welke Axis moet op één lijn komen is de hele klus, en al het andere volgt eruit.
tl;dr: Het samenvoegen van afbeeldingen is een schaalbeslissing voordat het een tekenende beslissing is. Zij aan zij matcht elke foto met de hoogste hoogte, stapelen lucifers met de breedste breedte, en een raster komt overeen met beide, daarom moet een raster ook kiezen tussen bijsnijden en ruimte verlaten. Gemeten op een 4032x3024 foto naast een 1170x2532 screenshot: Side by Side produceert een 5429x3024 canvas met de screenshot vergroot tot 1397x3024, stapelen levert een 4032x11750 canvas met de screenshot vergroot met een factor 3.4, en een twee-cels raster in covermodus houdt 70,2% van de foto en 49.4.4.100% in de spotlights. Kies de modus bij welke as u wilt behouden. de beeldfusie Tekent alles op het tabblad Browser, dus er wordt niets geüpload.
Waarom komen samengevoegde afbeeldingen er verkeerd uit?
Omdat de inputs verschillende vormen hebben en de meeste gereedschappen ze op elke maat tekenen die ze aankomen.
Een telefoonfoto is 4032 bij 3024 in landschap. Een screenshot van een telefoon is 1170 door 2532. Een scan is wat de scanner heeft besloten. Plaats een van deze twee op een rij op de oorspronkelijke grootte en een van hen torent boven de andere uit, waarbij dode ruimte alles wat er over is van de grotere afmeting vult. Dat leest als een fout in plaats van een lay-out, zelfs voor iemand die je niet kon vertellen waarom.
De oplossing is om te normaliseren, en de enige vraag is op welke as. Op een rij zijn de boven- en onderkanten wat het oog volgt, dus de hoogten moeten overeenkomen en elke foto neemt de breedte die zijn eigen beeldverhouding dan geeft. In een kolom zijn de linker- en rechterrand de lijn, dus de breedtes komen in plaats daarvan overeen. Een raster heeft beide randen om vast te houden, dus het moet bij beide passen, en dat is de modus waarin iets moet geven.
Dat is het hele ontwerp. Alles hieronder is wat daaruit volgt.
Wat doet Side aan zij met een lange screenshot?
Het vergroot het, soms meer dan je wilt.
Hier is het gemeten resultaat voor het bovenstaande paar, genomen uit de lay-outcode in plaats van geschat:
| manier | doek | foto getekend op | screenshot getekend op |
|---|---|---|---|
| naast elkaar | 5429 x 3024 | 4032 x 3024 | 1397 x 3024 |
| gestapeld | 4032 x 11750 | 4032 x 3024 | 4032 x 8726 |
Zij aan zij kwamen beide overeen met 3024, de grotere van de twee hoogten, dus de screenshot ging van 2532 tot 3024 pixels hoog. Dat is een vergroting van 19%, die op een screenshot van tekst zichtbaar is als je ernaar zoekt en onzichtbaar als je dat niet doet.
Stapelen is de dramatische. Afstemming met de bredere afbeelding maakte de screenshot van 1170 tot 4032 pixels breed, een factor 3,4, en het canvas kwam uit op 11.750 pixels hoog. De screenshot is nu het dominante object in een zeer lange afbeelding en elke letter erin is meer dan drie keer opgeschaald, wat geen enkele hoeveelheid resampling scherp maakt.
De les is niet dat één modus beter is. Het is dat de modus beslist welke foto wordt vergroot, dus kies degene wiens overeenkomende as je afbeeldingen al overeenkomen. Twee telefoonfoto's in het landschap delen een hoogte en gaan naast elkaar zonder schaal. Twee screenshots van dezelfde telefoon delen een breedte en stapelen perfect.
Wanneer moet je stapelen in plaats van naast elkaar te gaan?
Wanneer de inhoud naar beneden leest, of wanneer de afbeeldingen al even breed zijn.
Stapelen is goed voor een reeks: drie screenshots van een kassastroom, een voor en na waar de after eronder hoort, een gesprek dat in delen is vastgelegd. Het is ook goed wanneer de ingangen in dezelfde oriëntatie van hetzelfde apparaat kwamen, omdat dan de breedtes al overeenkomen en niets wordt geschaald.
Zij aan zij is goed ter vergelijking, waarbij het oog over moet bewegen in plaats van naar beneden, en voor alles wat in een bericht inline wordt bekeken, omdat een afbeelding van 4032 bij 11.750 wordt gescrolld in plaats van te zien.
Er is ook een praktische reden om de rij te verkiezen. De meeste plaatsen die één afbeelding accepteren, geven het weer op een vaste breedte, dus een zeer hoge fusie krimpt tot een snipper. Een rij van drie foto's op dezelfde hoogte blijft op die breedte leesbaar op een manier die een kolom van drie nooit doet.
Wat moet een raster beslissen dat een strip niet doet?
Wat te doen met een afbeelding die niet de vorm van de cel is, wat een vraag is die een strip nooit hoeft te stellen omdat hij maar één as vastzet.
Een raster pinnen beide. Elke cel heeft dezelfde grootte en een 4:3-foto past niet in een cel in de vorm van een screenshot van 9:19.5. Er zijn slechts twee eerlijke antwoorden en de tool vraagt je om tussen hen te kiezen:
- begrijpen Past op het hele plaatje in de cel en laat er ruimte omheen. Er gaat niets verloren en het raster ziet er een beetje rafelig uit omdat elke afbeelding op zijn eigen stukje achtergrond staat.
- Cover Vult de cel volledig door een gecentreerde uitsnede uit de afbeelding te nemen. Het raster ziet er gelijkmatig uit en de randen van de foto's zijn verdwenen.
Geen van beide is in het algemeen correct. Inhouden is goed voor screenshots, documenten, diagrammen en alles waar een edge informatie bevat. Dekmantel is goed voor gezichten, landschappen en textuur, waar een gecentreerde oogst is wat een persoon toch zou hebben gedaan.
De standaard hier is Cover, omdat de meest voorkomende reden om een raster te bouwen is dat het als één object moet worden gelezen.
Hoeveel van een foto gooit de cover weg?
Meer dan mensen verwachten als de inputs verschillende vormen hebben, en helemaal niets wanneer ze overeenkomen.
De celgrootte is het gemiddelde van de inputs, dus twee heel verschillende afbeeldingen produceren een cel die ook niet past. Voor het foto- en screenshot-paar in een tweecellig raster, rapporteert de lay-outcode precies wat er wordt getekend:
| beeld | Native | Bronregio getekend | Pixels bewaard |
|---|---|---|---|
| Photo | 4032 x 3024 | 2831 x 3024 | 70,2% |
| screenshot | 1170 x 2532 | 1170 x 1250 | 49,4% |
De helft van de screenshot is weg. Niet gecomprimeerd, niet geschaald: weggesneden, boven en onder, omdat een lang smal beeld dat in een bijna vierkante cel wordt geforceerd zijn uiteinden moet verliezen. Als die screenshot een ontvangstbewijs was, staat het totaal niet meer in de afbeelding.
Dezelfde bewerking op twaalf foto's van dezelfde camera haalt niets uit, omdat elke invoer de vorm van de cel al heeft. Dekking is goedkoop als de inputs het eens zijn en duur als ze dat niet doen, en de tool kan niet zeggen in welk geval je je bevindt. Schakel over naar het moment dat uw foto's verschillende vormen hebben en de randen ertoe doen.
Hoeveel kolommen moet een raster hebben?
Genoeg dat het resultaat breder is dan hoog, wat voor de meeste tellingen betekent dat de vierkantswortel naar beneden is afgerond.
De rijen volgen uit de kolommen en de telling, en de rekenkunde is meedogenloos. Twaalf afbeeldingen in vier kolommen zijn drie volledige rijen. Zeven afbeeldingen in drie kolommen zijn drie rijen met twee lege cellen aan het einde, die de lay-out als achtergrond verlaat in plaats van de laatste afbeelding uit te rekken om ze te vullen.
| Images | Kolommen | Resultaat |
|---|---|---|
| 4 | 2 | 2 x 2, geen gaten |
| 6 | 3 | 2x3, geen gaten |
| 7 | 3 | 3 rijen, twee cellen leeg |
| 9 | 3 | 3x3, geen gaten |
| 12 | 4 | 3x4, geen gaten |
Een telling die zuivere factoren is, is het waard om naar te streven. Als je zeven foto's hebt en de lege hoek je stoort, zijn de eerlijke oplossingen om er een te laten vallen, er een toe te voegen of deze te accepteren, omdat geen enkele rangschikking van zeven gelijke cellen een rechthoek is.
Waarom is er een hiaatinstelling en wat moet het zijn?
Omdat het aanraken van afbeeldingen als één foto wordt gelezen, en soms is dat verkeerd.
Een opening van nul is geschikt voor een panorama, want een voor en daarna zou eruit moeten zien als één frame, en voor alles waar de naad het punt is. Het is hier om die reden de standaardwaarde.
Een gat is goed als de foto's afzonderlijke dingen zijn die toevallig in één bestand staan: drie productfoto's, een reeks screenshots, een collage. Ergens tussen de 8 en 24 pixels doet het werk op afbeeldingen van een paar duizend pixels, en de slider gaat naar 80 voor groter werk. De opening wordt zowel rond de buitenkant als tussen de buitenkant aangebracht, dus het resultaat heeft een rand in plaats van afbeeldingen die van de rand afvloeien.
Een ding om te weten voordat u PNG kiest voor een fusie met een gat: de kloof is gevuld met wit, niet transparant gelaten. Het canvas is wit geverfd voordat er iets wordt getekend, omdat JPEG geen alfakanaal heeft en een ongeverfde gap-export als zwart. Een PNG van deze tool heeft daarom witte goten in plaats van transparante, wat van belang is als je van plan was het resultaat over een gekleurde achtergrond te leggen.
Hoe groot wordt het samengevoegde beeld?
Groter dan de inputs, en in het gestapelde geval veel groter, omdat er niets wordt weggeperst.
De canvasafmetingen zijn voorspelbaar vanuit de modus. Naast elkaar is de breedte de som van de geschaalde breedtes en de hoogte is de hoogste input. Gestapeld, de breedte is de breedste input en de hoogte is de som. Een raster is kolommen maal de cel plus de gaten.
Twaalf telefoonfoto's in een raster met vier kolommen komen uit op 16.208 bij 9.136 pixels, wat 148 megapixels is. Daar begint het volgende deel.
Waarom stopt de output bij 8.000 pixels?
Omdat voorbij een bepaalde grootte een browsercanvas niet meer werkt, en dat zegt het niet.
De limiet is geen specificatie. MDN stelt het duidelijk: De meeste browsers overschrijden 10.000 bij 10.000 pixels, iOS-apparaten zijn historisch gezien beperkt tot 4.096 met 4.096, en overschrijden de maximale afmetingen of het gebied "reageert het canvas onbruikbaar" met tekenopdrachten die stil falen. Er is geen uitzondering om te vangen. Je krijgt een leeg beeld, of helemaal niets. Per browser cijfers worden verzameld in de Testresultaten van canvasgrootte, wat de referentie waard is om te controleren voordat u een nummer aanneemt.
Dus de lay-out is verkleind tot een lange kant van 8.000 pixels in plaats van te mogen falen. Voor dat twaalf fotoraster is de schaalfactor 0,494, waarbij 16.208 bij 9.136 tot 8.000 bij 4.509 worden genomen, wat 36 megapixels is. Elke foto landt op ongeveer 1.976 bij 1.483 in plaats van 4.032 bij 3.024.
Dat is een echt verlies van resolutie, en het is de eerlijke handel: een 36 megapixelbeeld dat bestaat, verslaat een afbeelding van 148 megapixel die de browser weigert te tekenen. Als u de volledige resolutie van twaalf foto's nodig heeft, voeg deze dan in minder, grotere stukken samen of gebruik een desktoptool zonder canvas in de weg.
Moet het resultaat PNG of JPG zijn?
JPG voor foto's, PNG voor screenshots en alles met tekst of platte kleur.
Dit is de gewone regel en samenvoegen verandert het niet, maar samenvoegen maakt het wel meer belangrijk, omdat de output groot is. Een samenvoeging van 5429 bij 3024 van twee foto's is een bestand dat u zult opmerken bij PNG-formaten en die niet bij JPEG-kwaliteit 0,92 wordt, en dat is waar deze exporteert.
De omgekeerde stand houdt voor screenshots. JPEG's Chroma Subsampling en Block Transform zorgen voor zichtbare franjes rond scherpe tekstranden, en een samengevoegde strook screenshots zijn meestal scherpe tekstranden. PNG is verliesloos, dus de tekst blijft precies zo scherp als het was.
Een gemengde fusie heeft geen goed antwoord. Als een van uw invoer een screenshot met tekst is en een andere een foto, kies dan naar welke een lezer zal kijken.
Verliest fusies kwaliteit?
De tekening niet, maar de schaal kan, en het is de moeite waard om te weten welke welke is.
Pixels die op hun oorspronkelijke grootte worden getekend, worden gekopieerd, niet opnieuw gecomprimeerd. In een samenvoeging naast twee landschapsfoto's van dezelfde camera wordt helemaal niets geschaald, dus elke pixel in de uitvoer kwam van een invoerpixel.
De schaalvergroting is waar de kwaliteit naartoe gaat. Elke foto die is vergroot om bij een grotere buur te passen, wordt opnieuw bemonsterd, waardoor pixels worden uitgevonden die nooit zijn gefotografeerd. Een screenshot die 3,4 keer is vergroot om overeen te komen met de breedte van een foto, is zacht in een bepaalde manier dat hier geen instelling wordt opgelost. Niets wordt opgeschaald voorbij de grootste input op de as die overeenkomt, dus er is een plafond, maar een kleine foto naast een grote wordt nog steeds uitgerekt om het te bereiken.
Dan is er de export. Het kiezen van JPG hercodeert alles opnieuw, inclusief de invoer die al JPEG's waren, wat een tweede generatie lossy-compressie is. Het is hetzelfde mechanisme dat wordt beschreven in De audiogids over het extraheren van een track, in een ander medium: iets decoderen dat lossy is en het opnieuw comprimeren, is nooit gratis. Bij kwaliteit 0,92 zijn de kosten klein, en voor een samengevoegde fotostrip is het sowieso de juiste oproep.
In welke volgorde gaan de afbeeldingen?
De volgorde waarin je ze hebt toegevoegd, van links naar rechts of van boven naar beneden, en de enige manier om deze te wijzigen, is door er een te verwijderen en opnieuw toe te voegen.
Dit is de moeite waard om te weten voordat u twaalf bestanden tegelijk selecteert, omdat een bestandskiezer ze in zijn eigen volgorde overhandigt, die meestal alfabetisch is op bestandsnaam en soms niet. Voor een reeks die ertoe doet, zoals een kassastroom, is het toevoegen van ze één voor één in de volgorde die u wilt minder werk dan het achteraf repareren.
Dertig beelden is het plafond. Dat is geen canvaslimiet, het is een sanity-limiet: een samenvoeging van dertig telefoonfoto's is een 30 megapixel raster na de dop en een lay-out die niemand kan lezen.
Wat levert een samengevoegde afbeelding niet op?
Alles wat een ontwerptool doet, wat de eerlijke grens is van een samenvoegingstool.
Er zijn geen randen rond afzonderlijke foto's, geen afgeronde hoeken, geen slagschaduw, geen bijschriften, geen rotatie per afbeelding, geen overlapping, geen andere achtergrondkleur dan wit. Elke afbeelding wordt in de rechthoek getekend en dat is de hele functieset.
Als je een ingelijste collage met tekst wilt, is dat een ontwerpopdracht en een ontwerptool. Als je drie foto's in één bestand wilt plaatsen, zodat iets dat één afbeelding accepteert alle drie krijgt, dan is dat dit. De tweede als een zwakke versie van de eerste behandelen is de gebruikelijke bron van teleurstelling.
Twee aangrenzende tools dekken de gemeenschappelijke follow-ups: Tekst toevoegen aan een afbeelding voor een onderschrift en de beeldcompressor Wanneer een samengevoegd fotoraster groter wordt dan een uploadlimiet toestaat.
Waarom wordt dit uitgevoerd in de browser?
Omdat de beelden nooit ergens heen hoeven te gaan, en op het moment dat ze dat doen, is het de beslissing van iemand anders wat er met hen gebeurt.
De hele samenvoeging is een canvasbewerking. Uw bestanden worden gedecodeerd in het paginageheugen, op een canvas in het tabblad getekend en het canvas wordt teruggegeven als download via toBlob. Geen enkel verzoek bevat een afbeelding, er wordt niets naar een server geschreven en er is geen opgeslagen kopie voor iemand om te lekken of te vergeten.
Voor veel fusies is dat een aardige. Voor degenen met een screenshot van een bankafschrift, een foto van een document, een medische scan of een foto van een kind, is het de hele reden om een tool als deze te gebruiken in plaats van het eerste resultaat dat je vraagt om te uploaden.
De kosten zijn het hierboven beschreven canvasplafond en het feit dat zeer grote samenvoegingen worden beperkt door hoeveel geheugen het tabblad kan bevatten. Voor twee afbeeldingen, of twaalf, is geen van beide een limiet waaraan u zult voldoen.
