2010-02-01 26 views
32

Stiamo costruendo un'applicazione basata sul Web che richiede un'elaborazione dell'immagine intensa. Vorremmo che questo carico di elaborazione fosse sul client il più possibile e vorremmo supportare quante più piattaforme (anche i cellulari) il più possibile.Elaborazione delle immagini lato client

Sì, lo so, pio desiderio

Ecco le informazioni:

  1. L'elaborazione delle immagini è la rasterizzazione da alcuni dati. Pensa come creare un'immagine PNG da un file PDF.

  2. Non abbiamo molta potenza del server. Quindi l'elaborazione lato client è un must.

Quindi, stiamo considerando:

  1. Flash - più diffusa, ma da quello che ho letto ha strumenti di sviluppo poco brillanti. (e nessun supporto per iPhone/iPad per ora).

  2. Silverlight - ci consente di utilizzare .NET CLR, quindi un grande ++ (un sacco di codice è in .NET). Ma non è supportato per la maggior parte dei cellulari (si dice supporto Android in futuro)

  3. HTML5 + Javascript - probabilmente l'opzione più "portatile". Il problema è dover riscrivere tutto il codice di elaborazione dell'immagine in Javascript.

Eventuali pensieri o architetture che potrebbero aiutare? Precisazione: non ho bisogno di ulteriori idee su quali librerie sono disponibili per Silverlight e Javascript. Il mio dilemma è

  • scelta Silverlight significa nessun supporto per la maggior parte dei cellulari
  • scelgono Flash significa che dobbiamo riqualificare maggior parte del nostro codice e non iPhone/iPad supporto
  • HTML5 + Javascript dobbiamo riqualificare maggior parte del nostro il codice e non ancora pienamente supportato in tutti i browser
  • scegliendo due (Silverlight + Flash) saranno troppo costosa

Qualsiasi out-of-the-box o idee brillanti/alternative potrei mancare?

+0

bella domanda 1, in attesa di risposte ad accumularsi :) –

+0

Quanto bene i cellulari gestiscono l'elaborazione delle immagini? Includerei una sorta di test di velocità in modo che gli utenti possano vedere se il loro cellulare è all'altezza. –

+0

Le risposte di Joa Ebert e back2dos sono abbastanza buone. –

risposta

28

Questo è il tipo di problema che gli architetti del software incontrano continuamente. Come al solito, non esiste una soluzione ideale. Devi selezionare quale compromesso è più accettabile per la tua azienda.

Per riepilogare il problema, la maggior parte del software di elaborazione delle immagini è scritta in. NET. Ti piacerebbe eseguirlo lato client sui dispositivi mobili, ma c'è una penetrazione limitata di .NET sui dispositivi mobili. Le alternative con una maggiore penetrazione (es. Flash) richiederebbero di riscrivere il codice, che non puoi permetterti di fare. Inoltre, queste alternative non sono supportate su iPhone/iPad.

Ciò che si desidera idealmente è un modo per eseguire tutto il codice .NET sulla maggior parte delle piattaforme esistenti, tra cui iPhone/iPad. Posso dire con una certa sicurezza che al momento non esiste una soluzione di questo tipo, non esiste una risposta "silver bullet" che hai trascurato.

Quindi, su cosa sarà necessario scendere a compromessi? Mi sembra che, anche se si sviluppasse nuovamente in flash, mancherà comunque a un grande mercato (iPhone). E il software di riqualificazione è comunque estremamente costoso.

Ecco la soluzione migliore al tuo problema: devi scendere a compromessi sul tuo vincolo di "esecuzione lato client". Se si esegue il lato server, è possibile mantenere il codice esistente e anche distribuirlo a quasi tutti i client mobili, incluso l'iPhone.

Hai detto che la potenza del tuo server è limitata, ma la potenza di elaborazione del server è economica rispetto ai costi di sviluppo del software. In effetti, non è poi così costoso esternalizzare il componente del server e pagare solo quello che usi. È molto probabile che la tua applicazione abbia solo una bassa penetrazione per iniziare. Man mano che l'azienda cresce, potrai permetterti di aggiornare la capacità del tuo server.

Credo che questa sia la soluzione migliore per il tuo problema.

+1

grazie! risposta ben scritta :). questa è l'alternativa che abbiamo esaminato la scorsa settimana. premerò la risposta a questo ... a meno che non arrivi un proiettile magico d'argento;) – moogs

+3

+1, si veda anche la mia risposta. L'hardware è economico, i programmatori no. – Paolo

+0

Grazie Moog, contento che questo sia stato utile –

4

Sono sicuro che ci saranno Silverlight e JS che pubblicheranno degli esempi. Ecco alcuni editor di immagini scritto in ActionScript:

  1. Phoenix
  2. PhotoshopExpress

C'è un ImageProcessing library per iniziare. Plus PixelBender è disponibile in Flash Player 10, è veloce, viene eseguito in un thread separato e people fare alcune cose piuttosto matto con esso.

HTH

+0

funzionerebbe con flashlite? – moogs

+0

Flash Player 10.1 sta raggiungendo i cellulari (http://labs.adobe.com/technologies/flashplayer10/, http://blogs.adobe.com/flashplatform/2010/01/flash_player_101_coming_to_goo.html). Anche Elips Studio (http://www.openplug.com/resources/gallery) sembra un'ottima scelta per spingere i contenuti flash sul mercato mobile. –

4

Un aiuto per la parte di Silverlight:

C'è un editor di immagini Silverlight chiamato Thumba. E Nokola ne ha recentemente creato uno chiamato EasyPainter e fornirà anche il codice sorgente nel furure.

Per la conversione dell'immagine, consigliamo la libreria open source ImageTools che include anche alcuni effetti di base. Silverlight ha una classe per la manipolazione dei pixel di bitmap denominata WriteableBitmap. La libreria open source WriteableBitmapEx è una raccolta di metodi di estensione per WriteableBitmap di Silverlight. L'API WriteableBitmap è molto minimalista e c'è solo l'array Pixel grezzo per tali operazioni. La libreria WriteableBitmapEx tenta di compensare quella con i metodi di estensioni che sono facili da usare come i metodi incorporati. Gli ombreggiatori di pixel possono anche essere utilizzati per creare effetti rapidi e avanzati. Sebbene siano limitati dagli shader Shader Model 2, possono essere utilizzati per la sfocatura rapida, la colorazione e cose simili.

+0

Sì, ma il problema è con Silverlight è che non saremo in grado di supportare i cellulari. – moogs

+1

Certo, non ora, ma tu l'hai chiesto. :) BTW, ho appena aggiornato la risposta e ho aggiunto l'app EasyPainter di Nokola. Dovresti controllare anche tu. –

-1

Per come la vedo io, non esiste una soluzione che soddisfi tutte le esigenze. La tua migliore opzione, imo, è quella di andare con Flash e sperare che Adobe stabilisca un accordo con Apple per ottenere Flash su iPhone/iPad. Lo svantaggio principale, ovviamente, è che dovrai riscrivere gran parte del tuo codice.

Se il settore mobile non è assolutamente critico, scegliere l'opzione Silverlight per i motivi che hai menzionato. È anche possibile utilizzare Silverlight in modalità fuori browser per funzionare come applicazione desktop.

1

Non si dice in che lingua "tutto quel codice" si dovrebbe riscrivere. Potrebbe essere utile una traduzione semiautomatica in Javascript?

Forse potresti iniziare dal lato server, come suggerisce CraigS, e quindi spostare le funzioni nel client nel tempo invece di riscrivere tutto in una volta.

+2

è menzionato. "un sacco di codice è in .NET" (che sia C# o qualcos'altro è un punto minore). Probabilmente tutte le riscritture richiederebbero un nuovo codice per le librerie di classi base .NET. non presente in Javascript – moogs

2

Oltre alle altre risposte, un'altra opzione può essere una soluzione ibrida. Ad esempio, utilizza Flash/Silverlight per la maggior parte del pubblico di destinazione e utilizza l'elaborazione lato server per coloro che non la supportano (oppure potresti creare un'app nativa per iP [hone | ad])

Puoi devi fare qualcosa del genere comunque, dato che i cellulari che stai guardando potrebbero avere una potenza di elaborazione insufficiente a seconda di quanto complessa sia l'elaborazione dell'immagine.

Naturalmente hai ancora la possibilità di aggiornare il tuo server che, sebbene tu abbia attualmente scontato, è probabilmente far cheaper che dedicare tempo di sviluppo alla creazione/distribuzione/testing di una soluzione lato client.

7

Ospita l'elaborazione delle immagini su Amazon E2C, Azure o Google. IIRC E2C ha molti problemi comuni di elaborazione delle immagini confezionati e tutti pronti per essere utilizzati.

Azure terra probabilmente più familiare in termini di condivisione di codice come un servizio web

Basta pagare per cicli di CPU e trasferimenti/stoccaggio ecc

+0

Possiamo ospitare app su computer vision sul cloud? – coder9

3

NOTA BENE: Mi considero un sostenitore della piattaforma Flash. Ammiro l'enorme potenziale di Silverlight come tecnologia per implementare quasi tutti i contenuti .NET tramite il browser, ma ha una bassa penetrazione, è orribilmente commercializzato e, sebbene percepito come tale da molti (per lo più persone che non conoscono né Flash né Silverlight) - non è concorrente di Flash, tanto quanto Flash non è concorrente di Sliverlight. L'idealista in me ama l'idea di fare tutto in HTML + JS usando uno standard, invece di affidarsi a software proprietario di terze parti. Ma la verità è che JS è lento e l'API è limitata e le implementazioni di JS, HTML e CSS sono terribilmente incoerenti tra i browser.

Se vuoi davvero attenersi a .NET e sei così interessato a indirizzare l'iPhone e i suoi fratelli, allora potresti voler dare un'occhiata a MonoTouch.

Tuttavia, anche se questo potrebbe sorprendervi, sto per dirvi di usare Flash. :)

Perché? Il bit di elaborazione dell'immagine è la parte più piccola della tua applicazione. Qualunque cosa tu stia scrivendo, ne sono molto sicuro. Non so su Silverlight, ma in Flash i filtri utilizzati da "Thumba" e "EasyPainter" possono essere creati in un giorno, la maggior parte semplicemente usando ConvolutionFilter, ColorMatrixFilter, DisplacementMapFilter e BitmapData::paletteMap o anche semplicemente applicando uno dei other filters Flash offers out of the box . Qualsiasi cosa aggiuntiva può essere creata usando PixelBender, che è stato indicato da George. Il linguaggio del kernel è un sottoinsieme di C, quindi il porting dei filtri classici non dovrebbe richiedere troppo tempo. Anche alchemy (un back-end LLVM che utilizza Flash Player 10) sarebbe un'opzione che vale la pena investigare, sebbene non sia ancora molto stabile.

La parte più grande della vostra applicazione sarà un sacco di progettazione grafica, realizzazione grafica, logiche di business ecc Flash è davvero grande quando si tratta di semplice, ma ragionevolmente veloce immagine manipolazione e con il framework Flex e MXML si dispone di un potente strumento per creare in modo produttivo la GUI della tua app, che può interagire molto bene con una moltitudine di soluzioni server praticamente per qualsiasi piattaforma.

Inoltre, Flash dispone di una comunità grande e attiva, che offre tonnellate di tutorial, frammenti di codice, librerie e framework e un grande ecosistema, con strumenti di compilazione incrociata per fornire contenuti flash ad altre piattaforme (incluso il prossimo Flash CS5 o gli Elips citati). Non capisco, dove hai avuto l'impressione, che la piattaforma Flash manchi di strumenti di sviluppo. La differenza con la suite .NET è che sono forniti da una moltitudine di fornitori. L'imminente Flash Player 10.1 era già stato indicato da George, ma mai meno, volevo sottolineare, questo rende obsolete molte delle considerazioni cross-plattform.

Ultimo ma non meno importante, vorrei sottolineare haXe. Consente la compilazione in formato SWF, ma anche in C++, utilizzando la stessa API fornita da NME, a target the iPhone. Inoltre ci sono lavori in corso su un backend Android. Se non stai giocando per il lancio entro i prossimi 4-5 mesi, allora questa è sicuramente un'opzione.

+0

Mi dispiace, non ho visto la menzione di MonoTouch qui. Ottimo punto! ;) –

0

La soluzione migliore è utilizzare Silverlight (quindi è già pronto il codice). Se il client non può eseguirlo (telefoni cellulari, ecc.), Processarlo dal lato server.

È il miglior compromesso.

0

Dipende dal tipo di elaborazione dell'immagine e dall'esperienza dell'utente finale che si desidera utilizzare.

Mentre stai cercando di indirizzare i telefoni cellulari, l'elaborazione delle immagini dovrà prendere in considerazione il tipo di telefono che l'utente o il destinatario ha (se invia messaggi via SMS/MMS), poiché i telefoni diversi hanno schermi di risoluzione differenti e gestiscono diversi formati di immagine per immagini principali e miniature.

Suggerirei di considerare un'architettura di cloud ibrida come menzionato nelle note chiave di Microsoft PDC quest'anno. Ciò consentirebbe di avere il proprio server (s) per supportare l'applicazione, ma se si richiede capacità aggiuntiva a causa di ridimensionare nel cloud utilizzando AppFabric.

Inoltre, per massimizzare la disponibilità del mercato del prodotto estraendo l'elaborazione delle immagini su un'infrastruttura comune riutilizzabile, è possibile scegliere come target piattaforme diverse, sfruttando gli aspetti positivi in ​​ciascuna.

Ho lavorato a una soluzione che ha ospitato il lato server di elaborazione immagini e infrastruttura di consegna e poi ha creato diverse offerte di interfaccia utente che consentono vendite tramite desktop, MNO e AppStores. Può funzionare e dal punto di vista commerciale può offrire vantaggi in termini di economie di scala.

2

È possibile utilizzare Silverlight per tutti i client abilitati Silverlight e per i client non Silverlight, eseguire il lato server di elaborazione immagini. Poiché il codice Silverlight è C#, puoi raddoppiarlo per creare (principalmente) lo stesso codice di lavoro di Silverlight e non Silverlight (cioè server). Questo ti dà il meglio di entrambi i mondi.

3

Il problema è un obiettivo perfetto per il linguaggio di programmazione haXe. haXe è scritto per il web e può compilare JavaScript, Flash e Objective-C (probabilmente Java/.NET a breve). Quindi non scegli quale piattaforma vuoi investire ma in quale lingua. haXe è facilmente utilizzabile per un programmatore AcitonScript.

Non ha senso eseguire gli algoritmi di elaborazione delle immagini in una sandbox JavaScript quando Flash è disponibile perché sarà molto più veloce.Inoltre, non ha senso eseguire algoritmi pesanti di elaborazione delle immagini su un dispositivo mobile come l'iPhone con JavaScript. Vorrei solo supportare JavaScript come la peggiore soluzione di fallback.

Se non ti piace usare haXe, andrei con Flash. Puoi installare la tua applicazione Flash anche per iPhone se questo è il tuo problema. Questo è anche molto grande perché ottieni codice ARM nativo. Esistono in realtà ottimi strumenti per lo sviluppo professionale di Flash disponibili. FDT e IntelliJ IDEA sono due di loro. Il migliore haXe IDE è probabilmente FlashDevelop al momento della scrittura.

Quindi non utilizzerei assolutamente JavaScript come unica soluzione. haXe è perfetto per quello che cerchi di ottenere. Se non ti fidi o non vuoi investire in haXe, puoi utilizzare Flash a causa dello iPhone/iPad export.

A seconda del tuo caso, ti incoraggerei anche a guardare il cloud hosting come Amazon EC2 e Google AppEngine, ad esempio. I costi di hosting sono economici e il ridimensionamento sarà facile per il tuo compito. L'esperienza sarà molto migliore quando si tratta di operazioni complesse che possono impiegare molto tempo su un sistema desktop.

0

Perché non menzionare l'applet Java?

Lati positivi sono:

quasi tutto il supporto del browser? necessario installare JRE? tutto il supporto del sistema operativo Java forniscono Java kit Advanced Image, ma se c dll ++ può essere chiamato, che è meglio (JNI può chiamare C++ dll)