Gideon Sundbäck föddes i Sverige 1880 och uppfann blixtlåset. Mer korrekt är att han gjorde förbättringar på Elias Howes draglås. Men det är historia. Idag uppmärksammar Google Gideon:

Vi avslutar med en lite rolig historia om blixtlås:

Kunden i järnaffären: Har ni åskledare?

Expediten: Nej, men vi har blixtlås!

Häpp!

Tweet

Etiketter:Google

Instagram kommer ut på Androidplattformen, Facebook köper Instagram, ”alla” som har Instagram blir väldigt upprörda. Nu har Mark Zuckerberg sagt att de skall låta Instagram leva sitt egna liv. Jag vet inte om jag kommer tro på det i längden men uppriktigt sagt bryr jag mig inte. Jag är en av (få?) som inte har laddat med Instagram, förrän nu. Jag går alltså mot strömen och startar ett konto när Facebook går in och köper. Varför vet jag inte riktigt men ilskan hos användarna fick mig lite att fundera i riktningen att det kanske är en bra tjänst som är värd att prova.

Om 2 minuter skall jag registrera mig och börja ta bilder (DET HETER INTE ”TA KORT”, HAR MIN CHEF SAGT!). 🙂

Recension kommer…

Tweet

Etiketter:Facebook, Instagram

Webbdagarna. Smaka på ordet. Webbdagarna. Två dagar om webb tänker ni som inte var där. Slutsummeringen är att det faktiskt handlade mycket om att göra bra saker. Dvs. alla företag och personer skall göra bra saker. Joakim Jardenberg sammanfattade det med ”Do good shit”. Men det genomgående temat var att göra bra saker samt att göra det transparent. Att våga göra bra saker via sociala medier. Det fanns mängder med exempel på hur olika företag och organisationer använder sociala medier till att göra bra saker och att vara transparenta. Bland annat Ving och Viasat visade på detta.

Men om vi betänker det faktum att LinkedIn har ca 980 000 användare i Sverige, Facebook har 4 638 500 och Twitter ca 250 000 så är det idag i Sverige fler som inte har ett konto för sociala medier än de som inte har det. Det finns 260 260 personer som har Facebook som är över 64 år. 932 680 är mellan 13-19 år. Facebook har alltså en bra spridning på användarna. Men börjar vi fundera på hur många som faktiskt använder Facebook, dvs. loggar in och delar med sig, kommenterar mm, blir bilden lite annorlunda. Jag har en ganska strikt syn på vilka som blir mina vänner på Facebook, vilket gör att jag har 343 vänner. Av dessa uppskattar jag att ca 150 är någorlunda aktiva, ca 100 stycken är där ibland och 100 använder inte sitt konto.  Om det är ca 30% som inte använder sitt Facebookkonto innerbär det att av de 4 438 500 konton som finns i Sverige är det bara 3,1 miljoner konton som är aktiva. Tar vi bort ytterligare 5% som troligen är test och fejkkonton är vi nera i ca 2,9 miljoner konton. Det är alltså ca 6 miljoner svenskar som inte går att nå via Facebook. Alltså måste alla företag vara bra och göra ”Good shit” på sin webbplats och intranät också om vi skall hålla oss inom den digitala världen. Självklart skall alla organisationer och företag vara bra i grunden. Men om vi skärmar oss till webben, det heter faktiskt webbdagarna.

När det nu är influenser från Jocke Jardenberg och Johan Ronnestam som ringer kvar i öronen (Se hans föreläsning här). Det är nu upp till alla oss som besökte Webbdagarna att samla alla bra tankar och intryck och överföra dem till de digitala kanaler vi jobbar med på det egna företaget och åt kunder i de fallen vi jobbar som konsulter. Vi har också ett kollektivt ansvar att sprida kunskapen uppåt och visa ledningsgruppen att det finns ett värde i att göra bra saker. Det kommer troligen inte att vara en ny värld nästa vecka men om vi tillsammans blir en smart svärm som Adam Hassan pratade om i sitt framträdande och kollektivt föra fram vårt budskap.

Till sist vill jag bara passa på att säga en lite sak om vem som var snällast på Webbdagarna. Jo, det var Therese Reuterswärd!

Tweet

Etiketter:webdagarna

Många älskar produkten. Det rektangulära vitgröna plastpaketet går för de allra flesta tillbaka många år i tiden. Vi är många som med ett njutningsfullt leende har rivit av ett hörn och sakta klämt och bitit i oss denna ljuvliga hasselnötshistoria.

NötCrème finns på Facebook. Dom har en egen sida med närmare 30 000 personer fans. Frågan är hur många av dessa som löpande köper en NötCrème? Jag är dålig på att gissa här men det är säkert inte speciellt många. Företaget bakom produkten använder inte heller sidan speciellt mycket. För ett tag sedan basunerade de ut att Nötcréme kommer in en ny smak. Salmiak, dvs. en lakritssmak. Vänta nu lite. En Nötcréme som smakar lakrits? Varför då? De kände kanske att de måste förnya sig?

Recept för ökad försäljning?
Jag har ett bättre förslag. En gång i månaden. Förslagsvis på en torsdag, ska de lägga ut ett recept på en efterrätt där det ingår NötCrème. Tänk dig – kladdkaka med NötCrème-glasering, chokladmousse med NötCrème-smak…. Det tror jag skulle få fart på försäljningen! 30 000 fans x 5 NötCrème en gång in månaden blir 150 000 fler sålda enheter per månad. Visst kan det vara så att alla inte köper tänker du? Men ärligt… Det är NötCrème! Alla älskar det!

Tweet

Det är viktigt att hantera sitt varumärke strategiskt. Det är alla som har ett varumärke eniga om. Men alla tänker inte hela vägen. Jag läste innan jul boken om Steve Jobs. Hans nästan sjukliga drivkraft att lägga sig i de minsta saker i Apples butiker bara för att det speglar varumärket. Allt ifrån känslan av hur det är att köpa en produkt från Apple, till hur det är att packa upp produkten och sedan använda produkten. Allt ska andas premium.

Apple Store 5th Ave, NYC

Men det börjar ännu tidigare, innan den fysiska affären. Funderar du på att köpa en ny MacBook Pro? Då gör du säkerligen en del research på apple.se även om du gör det slutgiltiga köpet i den fysiska butiken. Då är det självklart viktigt att känslan av varumärket börjar förmedlas redan här. Som kund ska jag få samma känsla på webben som jag får i den fysiska butiken och det som produkten representerar. Apple är en föregångare, verkligheten får många företagare ser annorlunda ut. Vi har mycket att lära av Apple! Hur hänger upplevelsen för en kund ihop från webb, till att en säljare kommer på besök, eller att kunden kommer till en butik eller ett kontor till hur tjänsten och produkten blir vid ett köp? Det finns fortfarande de som tror att webbplatsen inte är viktigt. ”Nä, vi gör inte affärer via webben, vi gör affärer via människor”. Men – hänger inte allt ihop? Är inte alla delar olika beståndsdelar som tillsammans skapar ditt varumärke?

Vad säger din webb om ditt varumärke?
Ibland misstänker jag att vissa företag inte ens reflekterar över att deras webb besöks av en potentiell kund innan deras säljare dyker upp. I det läget bestäms mycket av vad som sedan händer. Om webbplatsen inte svarat upp mot den förväntade kvalitén mot en förväntad produkt kommer säljaren ha svårt att vända affären till en framgång. Det är därför all kommunikation hänger ihop. Allt från webben via broschyrer, kataloger, mässmontrar, besök av säljare till hur en butik eller ett kontor ser ut. Allt måste hänga ihop med den position som du vill ha på ditt varumärke. Det är därför en Apple Store ser väldigt annorlunda ut mot Överskottsbolaget. Våra förväntningar är på olika nivåer och skulle ÖB se ut so Apple Store på 5th Avenue i New York skulle inte det vara rätt heller. Allt måste hänga ihop, fast på rätt nivå, och det gäller även webbplatsen.

Tweet

Etiketter:Varumärke

I var och vart annat projekt man sitter i (i alla fall när det gäller e-handel eller integration) så skall det skalas bilder. De skall ha bestämda storlekar, bestämda bredder, de ska beskäras och ramas in.

GDI+ ligger under System.Drawing vilket har en liten drawback, ända upp till senaste versionen av .NET (4.5) så skriver Micosoft så här på MSDN:
Classes within the System.Drawing namespace are not supported for use within a Windows or ASP.NET service. Attempting to use these classes from within one of these application types may produce unexpected problems, such as diminished service performance and run-time exceptions. For a supported alternative, see Windows Imaging Components.
GDI+ ligger säkerligen på många av våra webbar och i många av våra Windows-tjänster och fungerar riktigt bra, men varför chansa i fortsättningen? Dessutom kan jag tycka att resultatet av det som GDUI+ genererar inte alltid är tillfredsställande ur en kvalité. Men det finns en lösning!

Windows Imaging Components

Det finns två sätt att arbeta med Windows Imaging Components (vidare kallat WIC). Det ena är via Windows Presentation Foundation (vidare kallat WPF) och det andra är via COM. Det senare alternativet kan vara användbart där vi har problem med trust eller vi inte vill programmera i något av de språk som tillhandahålls inom ramen för .NET. Men för den här gången kommer vi fokusera på C#.

Tanken jag har med detta lilla blogginlägg är att ge er alla lite hjälp på vägen, lite kod ni kan kopiera och utgå i från i era egna projekt. Så slipper ni skriva allt från början, vilket gör en övergång ganska mycket smidigare.

Jag har fokuserat på tre olika typer av bildomskalingar.

• En omskalning där vi håller en av sidorna konstant och låter den andra skala efter behov. Det här är det klassiska sättet att skala om bilder.
• Där vi använder en fixerad storlek (både höjd och bredd) på resultatet och lägger in vår omskalde bild i denna, så att den får plats.
• Samt en tredje variant där vi, likt vår förra variant, använder en fixerad storlek på bilden men den här gången så skalar vi ner bilden så att en av sidorna exakt matchar en av resultatet sidor och sedan beskär vi bort överflödet av bilden.

Klassisk omskalning

Den klassisk omskalningen är bara ”vänligt” implemneterad, med det menar jag att den alltid kommer att skala om en bild proportionellt. Den väljer alltid den skalning som blir minst om man anger båda parametrarna, annars kan man skicka in 0 (noll) på en av dem för att vara övertygad om att skalning sker med den aktuella parametern i avseende.

private BitmapFrame ResizeImage(BitmapSource input, int width, int height) {
  double newHeightRatio = (height / (double)input.PixelHeight);
  double newWidthRatio = (width / (double)input.PixelWidth);

  if (newHeightRatio <= 0 && newWidthRatio > 0)
    newHeightRatio = newWidthRatio;
  else if (newWidthRatio <= 0 && newHeightRatio > 0)
    newWidthRatio = newHeightRatio;

  var scale = Math.Min(newWidthRatio, newHeightRatio);
  if (scale > 1)
    scale = 1;
  var target = new TransformedBitmap(input, new ScaleTransform(scale, scale));
  return BitmapFrame.Create(target);
}

WPF innehåller en så kallad BitmapSource som transformerar vår bild, denna tar emot en transformationstyp och .NET tillhandahåller några standardiserade. Dessa är

• MatrixTransform
• RotateTransform
• ScaleTransform
• SkewTransform
• TranslateTransform

Just nu kommer jag enbart att fokusera på ScaleTransform eftersom det är den som är mest intressant för mig, men här kan vi lätt modifiera koden ovan för att exempelvis rotera eller skeva en bild istället.

Det här sättet att skala bilder med WPF är det snabbaste och ger en helt godkänd bildkvalité. Vi har inte heller någon möjlighet att direkt påverka bilddjupet, resultatbilden kommer i detta fall att ha samma upplösning (DPI) som orginalet.

Det här är ressultatet av en sådan här omskalning. Jag har talat om att bilden skall vara 200 px hög.

Det inte den här metoden ger möjlighet till är att välja vilken algoritm som skall användas för omskalningen. För att kunna ange detta måste vi använda ett annat sätt när vi skalar om bilderna, och förlorar då effektivitet. Det här är en avvägning man får göra i fall till fall, dock tycker jag att den algoritm som används av exemplet ovan ger en bra bildkvalité till en bra hastighet.

public BitmapFrame Resize(BitmapFrame input, int width, int height, BitmapScalingMode salingMode, int dpi) {
  var group = new DrawingGroup();
  RenderOptions.SetBitmapScalingMode(group, scalingMode);
  group.Children.Add(new ImageDrawing(photo, new Rect(0, 0, width, height)));
  var targetVisual = new DrawingVisual();
  var targetContext = targetVisual.RenderOpen();
  targetContext.DrawDrawing(group);
  var target = new RenderTargetBitmap(width, height, dpi, dpi, PixelFormats.Default);
  targetContext.Close();
  target.Render(targetVisual);
  var targetFrame = BitmapFrame.Create(target);
  return targetFrame;
}

I exemplet ovan kan man se hur vi kan välja både skalningsmetod och djup i bilden som vi producerar. Vi använder en helt annan metodik för att skala bilderna vilken tar mer kraft från systemet.

Skala en bild och placera den i en ram

Om man alltid vill ha en fast storlek på bilderna, tillexempel till en produklista där det skulle se otroligt dumt ut om bilderna var i olika bredder eller höjder, kan man välja att lägga dem i en ”omgivande ram”. Lösningen är vanlig och gör det mycket enklare att designa webbplatser.

public BitmapFrame ResizeAndFit(BitmapSource input, int width, int height) {
  if (input.PixelWidth == width && input.PixelHeight == height)
    return BitmapFrame.Create(input);

  if (input.Format != PixelFormats.Bgra32 || input.Format != PixelFormats.Pbgra32)
  input = new FormatConvertedBitmap(input, PixelFormats.Bgra32, null, 0);

  var scale = Math.Min((double)width / input.PixelWidth, height / (double)input.PixelHeight);
  if (scale > 1)
    scale = 1;

  var x = (int)Math.Round((width - (input.PixelWidth * scale)) / 2);
  var y = (int)Math.Round((height - (input.PixelHeight * scale)) / 2);
  var scaled = new TransformedBitmap(input, new ScaleTransform(scale, scale));
  var stride = scaled.PixelWidth * (scaled.Format.BitsPerPixel / 8);
  var result = new WriteableBitmap(width, height, scaled.DpiX, scaled.DpiY, scaled.Format, null);
  var colorFrame = GetColorBitmap(width, height, Brushes.White);
  var colorFrameStride = colorFrame.PixelWidth * (colorFrame.Format.BitsPerPixel / 8);
  var colorFrameData = new byte[colorFrame.PixelHeight * colorFrameStride];
  var data = new byte[scaled.PixelHeight * stride];

  colorFrame.CopyPixels(colorFrameData, colorFrameStride, 0);
  scaled.CopyPixels(data, stride, 0);

  result.WritePixels(new Int32Rect(0, 0, width, height), colorFrameData, colorFrameStride, 0, 0);
  result.WritePixels(new Int32Rect(0, 0, scaled.PixelWidth, scaled.PixelHeight), data, stride, x, y);

  return BitmapFrame.Create(result);
}

private BitmapSource GetColorBitmap(int width, int height, Brush color) {
  var renderBitmap = new RenderTargetBitmap(size.Width, size.Height, 96, 96, PixelFormats.Pbgra32);
  var drawingVisual = new DrawingVisual();
  using (var context = drawingVisual.RenderOpen()) {
    context.DrawRectangle(color, null, new Rect(0, 0, size.Width, size.Height));
  }
  renderBitmap.Render(drawingVisual);
  return renderBitmap;
}

Den här typen av omskalning blir lite mer avancerad. Här måste vi nämligen rita ut vår omskalde bild i en ytterligare bild. Först så ser vi till att båda våra bildformat är på samma format, om vår inkommande bild inte är 32bitars RGB (Bgra32) så omvandlar vi källan till detta, exempel på andra format kan vara 16bitars RGB eller CMYK.

Efter detta skalar vi ner bilden så att den får plats i vår ram. Det vi gör är att vi räknar ut proportionell skalning i både X- och Y-led för att sedan välja den som är minst. Det kommer vara den skalfaktor vi använder för att se till att bilden får plats i vår destinationsstorlek.

Som standard är vår nya skrivbara bitmap transparent, detta fungerar mycket bra för PNG och kanske till och med är önskvärt. Det vi i så fall gör är att vi raderar våran colorFrame från koden ovan och låter inte denna skrivas till bilden. När vi skalar foton är det i de flesta fall önskvärt att spara bilderna som JPEG eftersom det tar minst plats. JPEG stödjer inte transparens och därför måste vi måla vår bakgrund i en önskad färg.

Vi kopierar sedan över vår bakgrund och därefter vår bild till vår destination och returnerar denna. Omskalningen är klar!

Det här är resultatet. Jag har talat om att jag vill ha en bild som är 500 px bred och 200 px hög, och med blå bakgrund.

Skala en bild och beskär det som inte får plats

Om du vill ha en fast bildstorlek men inte vill ha en ”ful” färgad ram kring din bild så kan det vara nog så bra att beskära bort en del av bilden. Om dina orginalbilder ligger väldigt nära dina omskalade bilder i proportioner så är detta ett utmärkt alternativ, på bilderna som jag använder blir resultatet dessvärre mycket sämre. s

public BitmapFrame ResizeAndCrop(BitmapSource input, int width, int height) {
  if (input.PixelWidth == width && input.PixelHeight == height)
    return BitmapFrame.Create(input);

  var useScaleH = (width / (double)input.PixelWidth) * input.PixelHeight;
  var newSizeH = 0;
  var newSizeW = width;
  if (useScaleH < height) {
    var newSizeH = height;
    var newSizeW = 0;
  }

  var scaled = ResizeImage(input, newSizeW, newSizeH);
  var x = ((scaled.PixelWidth - width) / 2);
  var y = ((scaled.PixelHeight -height) / 2);
  var stride = scaled.PixelWidth * (scaled.Format.BitsPerPixel / 8);
  var result = new WriteableBitmap(width, height, scaled.DpiX, scaled.DpiY, scaled.Format, null);
  var data = new byte[scaled.PixelHeight * stride];
  var copyWidth = scaled.PixelWidth - (scaled.PixelWidth - width);
  var copyHeight = scaled.PixelHeight - (scaled.PixelHeight - height);
  if (x < 0) {
    x = 0;
    copyWidth = scaled.PixelWidth;
  }
  if (y < 0) {
    y = 0;
    copyHeight=scaled.PixelHeight
  }

  scaled.CopyPixels(data, stride, 0);
  result.WritePixels(new Int32Rect(x, y, copyWidth, copyHeight), data, stride, 0, 0);

  return BitmapFrame.Create(result);
}

Det här ser mer avancerat ut än vad det är. Vi måste först räkna ut vilken sida som, när vi skalat ner bilden, kommer att vara lika stor som den nya bilden medan den andra sidan är större. När vi gjort det kan vi skala ner bilden proportionellt.

Vi skapar därefter en destinationsbild som är exakt så stor som vi vill ha den. Eftersom vår nedskalade bild är större än denna måste vi räkna ut en ram som skall användas för att beskära bilden. Det gör vi genom att räkna ut hur mycket som ”hänger över” i bredd- och höjdled. Vi centrerar bilden genom att dela dessa värden i hälften och koperar nu över de pixlar som ligger inom ramen till vår destinationsbild.

Viktigt att notera här är att om orginalbilden är mindre än destinationsbilden så kommer vi bara kopiera över bilden till det övre vänstra hörnet. Det är för att vi inte vill sträcka ut bilden och förstöra den. Det bästa är inte använda denna metod vid sådana bilder, utan i stället lösa det problemet på annat sätt, exempelvis genom att lägga en ram kring den.

Det här är resultatet. Jag har talat om att bilden skall vara 500 px bred och 200 px hög. Min orginalbild är stående och denna liggande, därför förlorar vi mycket av bilden. Två bildformat som ligger nära varandra i proportioner resulterar

Avkoda och koda bilder från disk/ström.

För att allt det här ska fungera behöver du också några småsaker, exempelvis en bild-decoder och en bild encoder. Självklart finn detta inbyggt och är inte direkt rocket-sience. Här kommer lite exempel:

Stream orginalImage = null; //Load stream from image-file or like.
var orginalImageDecoder = BitmapDecoder.Create(
                                    orginalImage,
                                    BitmapCreateOptions.PreservePixelFormat,
                                    BitmapCacheOption.None);

BitmapSource source = orginalImageDecoder.Frames[0];

När du skall spara dina omskalade bilder kan du göra det i sex format som Microsoft tillhandahåller. Dessa är

• BmpBitmapEncoder
• GifBitmapEncoder
• JpegBitmapEncoder
• PngBitmapEncoder
• TiffBitmapEncoder
• WmpBitmapEncoder

alla dessa format används på samma sätt som nedan. JpegBitmapEncoder har dessutom möjlighet att sätta kvalité för kompressionen.

Stream resizedImage = null; //Init a writable stream for the destination
BitmapFrame resizedImageFrame = null; //Frame from one of the resize algorithms above.
var targetEncoder = new JpegBitmapEncoder(){
    QualityLevel = 85;
};
targetEncoder.Frames.Add(resizedImageFrame);
targetEncoder.Save(resizedImage);

Jag hoppas att det här har väckt dina tankar lite kring att kanske använda WPF för att göra din bildmanipulering i framtiden.

Tweet

Etiketter:.NET, asp.net, bildhantering, bitmap, c#, gdi+, gif, jepeg, png, resize, skala, system.drawing, tiff, wic, Windows, wpf