Java snel genoeg voor 2D imaging?

[Verwijderd]

Ik speel met het idee om zelf een utility te maken voor foto beheer (iets in de trend van Apple Aperture):
-Raw processing
-categorieseren en zoeken van foto's
-groeperen van foto's die genomen zijn binnen enkele seconden (het maken van stacks)
-real time voorbeelden van raw bewerkingen (levels, color, sharpness)
-real time zoom tool.

Ik weet dat veel mogelijk is in java, zoniet alles, maar mijn (zeer beperkte ) ervaring met java 2D was niet echt positief ivm snelheid.

Zou C++ een goed alternatief zijn of moet C#?
(mijn vraag is niet: wat is beter, mijn vraag is: gaat java echt zoveel trager zijn als de c++ die zonder intermediate taal werkt)

[NMe]

Voor zover ik weet is Java in de laatste paar versies aanzienlijk sneller geworden. Persoonlijk zou ik toch eerder denken aan C++, maar dat komt omdat ik daar zelf meer ervaring mee heb en omdat ik weet dat het daarmee mogelijk is om zo'n applicatie performant te krijgen. In hoeverre dat met Java kan weet ik niet. C# schijnt dan weer wat trager te zijn dan C++, maar ook daar kan ik weinig uitspraken over doen, omdat ik er niet mee gewerkt heb.

Wat overigens belangrijker is: waar heb je ervaring mee? Kun je met een bepaalde taal al werken? En kun je dat op een niveau waarmee je denkt dit te kunnen maken?

[MBV]

Waarom maak je geen proof of concept? Ik neem aan dat je weet wat voor soort bewerking erbij komt kijken. Plaatje tekenen en helderheid veranderen met een schuifje zou volgens mij genoeg meoten zijn. Als je ziet dat dat wél goed loopt in C++ maar niet in Java of C# zou ik eens achter mijn oren krabben, anders zou ik voor de taal waarin je de meeste ervaring hebt gaan.

[Valor]

Als ik jouw was zou ik voor C# gaan. Het is prima te gebruiken voor jouw doel einden. Het grote voordeel aan C# is dat je vele malen makkelijk een User interface kan maken dan in C++.

Mocht je echter een high performance programma willen maken. Denk dan meer aan games en render software dan is C++ geschikter maar in dit geval kan je prima af met C#. Java zou ik 100% uit de weg gaan is niet voor uit te branden.

[NMe]

Valor schreef op maandag 21 november 2005 @ 01:01:
Als ik jouw was zou ik voor C# gaan. Het is prima te gebruiken voor jouw doel einden. Het grote voordeel aan C# is dat je vele malen makkelijk een User interface kan maken dan in C++.

Wel eens van (bijvoorbeeld) Borland C++ Builder gehoord?

[RayNbow]

Valor schreef op maandag 21 november 2005 @ 01:01:
Mocht je echter een high performance programma willen maken. Denk dan meer aan games en render software dan is C++ geschikter maar in dit geval kan je prima af met C#. Java zou ik 100% uit de weg gaan is niet voor uit te branden.

Ik ken een paar 2D Java games (side scrollers) die perfect te spelen zijn.

[Verwijderd]

in java en .net heb ik al enkele jaren ervaring, maar geen in c++ (alleen theoretische kennis).
Nu als ik de applicatie graag berekeningen wil laten doen door de grafische kaart, kan dit dan ook door .net of java. Want ik dacht dat die echt wel (beide) afschermen van wat er onder de schermen gebeurd.

Stel dat ik 100 raw bestanden moet binnenhalen van elk 8 mb. Thumbnails zouden dynamisch groter gemaakt moeten worden (via een slider). Via bepaalde classes en methodes weet ik dat je images op je screen kunt tekenen in .net op een bepaalde resolutie maar ik geloof dat ik daar verder dan wel geen controle over heb.

[Alarmnummer]

Java2d kan ook gebruik maken van hardware acceleratie (opengl) en je kunt ook direct in het videogeheugen schrijven (check volatileimage). En verder haal je de meeste performance uit algoritme optimalisaties (maar dat hoef ik je vast niet te vertellen).

[ Voor 35% gewijzigd door Alarmnummer op 21-11-2005 08:33 ]

[Zoida]

Java kan echt wel snel genoeg zijn om grafisch te werken hoor. Natuurlijk is het wat trager dan bvb C++, maar vergelijkbaar met de snelheid van bvb C# of Visual Basic .NET (deze laatste zijn even "snel").
Het ligt aan je persoonlijke voorkeur waarin je wilt programmeren. Ik denk dat elke pc van de laatste paar jaar snel genoeg moet zijn voor redelijke prestaties in java. Let gewoon op dat je ook een recente Java SDK gebruikt (Die van na 1.5 heeft ook nog eens extra leuke features zoals generics )
Vooral leuk is dat indien je Java gebruikt, je je programma ook kan gebruiken op een Linux of mac

[Janoz]

Java is wel snel genoeg voor alle bewerkingen. Wat mischien nog wel een probleem kan worden is dat de VM vaak van te voren een maximum hoeveelheid geheugen heeft. Dit kan, zeker bij het bewerken van raw images nogal voor problemen zorgen. Hier zou je dus nog even naar meoten kijken.

[JKVA]

Dat geheugen kun je instellen. Er zijn twee parameters voor. Ik weet ze zo snel niet uit mijn hoofd, maar ze staan vast wel ergens in een tutorial ofzo.

Verder is Java2D prima geschikt voor het bewerken van images d.m.v. Java2D. De performance mag ook geen probleem zijn, zeker niet als je 1.5 gebuikt en VolatileImages.

Succes ermee

[Johnny]

Ik heb ook weleens zoiets gedaan met Java 2D en enkele honderden multi-megapixel foto's, het grootste probleem is dan de hoeveelheid geheugen, maar dat heb je in iedere taal. Je moet in Java alleen bij het opstarten een hogere limiet opgeven. Vervolgens kun je heel goed om alle beperkingen heenwerken door gebruik te maken van thumbnails, caches, en proxies.

Voor de bewerkingen op de foto's heb je ook weer een heleboel manieren. Sommige zijn retetraag, andere supersnel.

Het grootste probleem zal voor jou waarschijnlijk zijn om RAW-afbeeldingen in te lezen van verschillende cameramerken, er zijn standaard namelijk niet zoveel import-filters beschikbaar voor Java.

[Janoz]

In het algemeen zitten er in RAW formaten geen rocketsience compressie algoritmen. Een import zal dan ook niet zo heel lastig te schrijven zijn.

[PrisonerOfPain]

Verwijderd schreef op maandag 21 november 2005 @ 08:27:
in java en .net heb ik al enkele jaren ervaring, maar geen in c++ (alleen theoretische kennis).
Nu als ik de applicatie graag berekeningen wil laten doen door de grafische kaart, kan dit dan ook door .net of java. Want ik dacht dat die echt wel (beide) afschermen van wat er onder de schermen gebeurd.

De bewerkingen die je noemt (waarvan de sloomste toch wel de kernel filter - sharpen - is) hoef je echt niet over de videokaart uit te voeren om 'm snel te laten zijn. Zolang je gebruik kunt maken van pointers (C++ en C#) hoeft het helemaal geen problemen op te leveren. Ik heb geen idee hoe java het afhandeld, maar PHP is er eigenlijk niet geschikt voor en wel om die reden. Andere programmeertalen ook, de pointer berekeningen maken de bewerking snel. Volgens mij heb ik hier nog wel een C# test applicatie van liggen welke een simpele color invert uitvoert. Met pointers ben je binnen een fractie van een seconde klaar terwijl de 'method call methode' er toch al vlug een aantal seconden over doet. (De afbeelding was niet eens zo absuurd groot, overigens.)

[Johnny]

Janoz schreef op maandag 21 november 2005 @ 14:18:
In het algemeen zitten er in RAW formaten geen rocketsience compressie algoritmen. Een import zal dan ook niet zo heel lastig te schrijven zijn.

Het algoritme is ook niet het probleem, maar het uitlezen van metadata, het gebrek aan documentatie en het feit dat er een heleboel verschillende RAW-formaten zijn die net even iets anders in elkaar zitten maakt het een vervelend klusje.

[ronaldmathies]

JKVA schreef op maandag 21 november 2005 @ 10:27:
Dat geheugen kun je instellen. Er zijn twee parameters voor. Ik weet ze zo snel niet uit mijn hoofd, maar ze staan vast wel ergens in een tutorial ofzo.

Verder is Java2D prima geschikt voor het bewerken van images d.m.v. Java2D. De performance mag ook geen probleem zijn, zeker niet als je 1.5 gebuikt en VolatileImages.

Succes ermee

De parameters -Xmx voor de maximale hoeveelheid (-Xmx 512M is maximaal 512 Megabyte) -Xms is de minimale hoeveelheid.

[Verwijderd]

betreffende de raw:
http://www.through-the-lens.net/
deze toolset ga ik eens uitproberen als basis om raw files te tonen.

[Janoz]

PrisonerOfPain schreef op maandag 21 november 2005 @ 15:06:
[...]

De bewerkingen die je noemt (waarvan de sloomste toch wel de kernel filter - sharpen - is) hoef je echt niet over de videokaart uit te voeren om 'm snel te laten zijn. Zolang je gebruik kunt maken van pointers (C++ en C#) hoeft het helemaal geen problemen op te leveren. Ik heb geen idee hoe java het afhandeld, maar PHP is er eigenlijk niet geschikt voor en wel om die reden. Andere programmeertalen ook, de pointer berekeningen maken de bewerking snel. Volgens mij heb ik hier nog wel een C# test applicatie van liggen welke een simpele color invert uitvoert. Met pointers ben je binnen een fractie van een seconde klaar terwijl de 'method call methode' er toch al vlug een aantal seconden over doet. (De afbeelding was niet eens zo absuurd groot, overigens.)

Een fatsoenlijk en snel toegankelijke dataset maken de berekeningen snel. Dat hoeft niet perse met de hand geimplementeerde pointer berekeningen te zijn. Met een normale 2D array van longs bereik je hetzelfde.

Johnny schreef op maandag 21 november 2005 @ 15:18:
[...]


Het algoritme is ook niet het probleem, maar het uitlezen van metadata, het gebrek aan documentatie en het feit dat er een heleboel verschillende RAW-formaten zijn die net even iets anders in elkaar zitten maakt het een vervelend klusje.

Daar heb je inderdaad wel gelijk in, maar zodra je (uit)gevonden hebt wat de indeling is lijkt het me een stuk makkelijker te implementeren dan een cosinus/fourier transformatie.

[MSalters]

Hmmm...leuke hypothesen allemaal. Nu weet ik dat bijvoorbeeld line staggering een fors verschil kan maken, en dan vergelijk je C++ met C++ code. De aanname dat willekeurige Java code wel ongeveer net zo snel zal zijn als willekeurige C++ code is dus behoorlijk uit de lucht gegrepen. Sowieso is de snelste implementatie vrijwel altijd een SIMD variant, bij voorkeur ook nog multi CPU (maar niet multithreaded!)

(Line staggering is het verschillend padden van elke rij pixels. Als je namelijk pixel X,Y mapt op X+W*Y, en X, Y+1 op X+Y*W+W, en W is een veelvoud van je cache line (wat vaak het geval is met machten van 2), dan zitten de geheugenadressen op een veelvoud van de grootte van de cache line. Dat is lang niet altijd de snelste oplossing. Een paar bytes extra helpt soms een heleboel, en met W=1024 is 1% geheugenoverhead het probleem niet.)

[Verwijderd]

MSalters schreef op maandag 21 november 2005 @ 21:18:
Hmmm...leuke hypothesen allemaal. Nu weet ik dat bijvoorbeeld line staggering een fors verschil kan maken, en dan vergelijk je C++ met C++ code. De aanname dat willekeurige Java code wel ongeveer net zo snel zal zijn als willekeurige C++ code is dus behoorlijk uit de lucht gegrepen. Sowieso is de snelste implementatie vrijwel altijd een SIMD variant, bij voorkeur ook nog multi CPU (maar niet multithreaded!)
[..]

Leuk dat jij dat weet, en je zult ongetwijfelt gelijk hebben, maar hoe denk je ons van je gelijk te kunnen overtuigen? Ik bedoel, heb je het getest? En wat waren de resultaten?

[Janoz]

MWah, in principe is dat een redelijk bekend probleem. Stel je cache is 1024 groot en je plaatje is 1024 breedt. Pas je nu een kernel bewerking toe die iets met het huidige pixel en de pixel eronder doet, dan vult de cache zich om en om met de huidige rij en de volgende rij. Een soort worst case caching scenario. In dat geval zou het bijvoorbeeld handiger kunnen zijn om per pixel in de kernel het volledige beeld te doorlopen ipv voor elke kernelpixel de afbeelding te doorlopen.

[JeroenTheStig]

Valor schreef op maandag 21 november 2005 @ 01:01:
Als ik jouw was zou ik voor C# gaan. Het is prima te gebruiken voor jouw doel einden. Het grote voordeel aan C# is dat je vele malen makkelijk een User interface kan maken dan in C++.

Mocht je echter een high performance programma willen maken. Denk dan meer aan games en render software dan is C++ geschikter maar in dit geval kan je prima af met C#. Java zou ik 100% uit de weg gaan is niet voor uit te branden.

Typisch een gevalletje 'de melk horen klotsen maar niet weten waar de tepel hangt'