|
|
 | Langsom nedskalering med blurr.
Fra : Thorbjørn Ravn Ander~ |
Dato : 24-07-07 15:12 |
|
Jeg har for et stykke tid siden skrevet et program der læser scannede
A4-sider ind, utydeliggør dem med en ConvolveOp med en 3x3 kerne, og
nedskalerer ved at tegne billedet på et BufferedImage i den rigtige
størrelse. Herefter gemmes som en JPG-fil.
Utydeliggørelsen er nødvendig for at resultatet er læseligt med
indskannede matriksprinterudskrifter.
Det går ret langsomt, og jeg har derfor kigget på at bruge
AreaAveragingScaleFilter i stedet med JIMI, men det går ikke hurtigt
nok da den lider af et seriøst hastighedsproblem, som jeg nu sidder og
kigger på, og ikke rigtigt kan få knækket. Mine analyser går i at det
er den unødigt komplicerede ColorModel-håndtering der gør skidtet
sløvt.
De indlæste sider er i RGB i TIFF-filen men kan i praksis omformes til
gråtoner uden tab af funktionalitet. Det skal køre i rå Java 1.4
eller 1.5 på en headless maskine (dvs 100% java eller
JRE-funktionalitet), der ikke er superhurtig.
Jeg har kigget på tiltag der forsimpler konverteringen og ColorModel
men det giver grimme resultater eller går ikke hurtigere alligevel.
Jeg vil derfor gerne høre folks mening og gerne kode om:
* Brug af JIMI til at foretage konverteringen. Overvejer at
modificere TIFF-dekoderen til at indlæse som gråtonebillede.
* Brug af JAI hele vejen igennem. Det er ikke helt nemt at gennemskue
:(
* Brug af Graphics2D til at give bedre grafik - giver ikke meget ved
headless.
* Bide i det sure æble, og konvertere de nødvendige rutiner fra NetPBM
fra C til Java (jeg kan pt ikke bruge native kode).
* Eller noget helt andet?
Det vigtige er læseligheden af det nedskalerede og hastigheden -
eksakthed er ikke så vigtig.
Eller skal jeg oversætte ovenstående til engelsk og gå i de
internationale grupper? :)
Alle tilbagemeldinger værdsat :D
--
Thorbjørn Ravn Andersen
| |
 Thorbjørn Ravn Ander~ (03-08-2007)
| Kommentar
Fra : Thorbjørn Ravn Ander~ |
Dato : 03-08-07 18:38 |
|
nospam0000@gmail.com (Thorbjørn Ravn Andersen) writes:
> * Brug af JAI hele vejen igennem. Det er ikke helt nemt at gennemskue
Der viste sig at være en sort/hvid til gråtonekonvertering heri der
var mærkbart hurtigere. Efter at have skrevet det om til ren JAI,
kørte det ok.
Det skal lige nævnes at IBM's java var 30% hurtigere end Sun's til
lige det nummer her.
--
Thorbjørn Ravn Andersen
| |
Arne Vajhøj (04-08-2007)
| Kommentar
Fra : Arne Vajhøj |
Dato : 04-08-07 04:20 |
|
Thorbjørn Ravn Andersen wrote:
> Det skal lige nævnes at IBM's java var 30% hurtigere end Sun's til
> lige det nummer her.
Der er faktisk ofte en pæn forskel på SUN, IBM, BEA og Oracle
med hensyn til performance.
Arne
| |
 Thorbjørn Ravn Ander~ (04-08-2007)
| Kommentar
Fra : Thorbjørn Ravn Ander~ |
Dato : 04-08-07 09:57 |
|
Arne Vajhøj <arne@vajhoej.dk> writes:
> Der er faktisk ofte en pæn forskel på SUN, IBM, BEA og Oracle
> med hensyn til performance.
Det er bare ikke nemt at hitte nogen konkrete oversigter over hvor
forskellene ligger således at man på forhånd kan sige - hov, her var
det måske en ide at overveje et JVM-skifte.
Vidste iøvrigt ikke Oracle havde deres egen JVM.
--
Thorbjørn Ravn Andersen
| |
Arne Vajhøj (06-08-2007)
| Kommentar
Fra : Arne Vajhøj |
Dato : 06-08-07 02:47 |
|
Thorbjørn Ravn Andersen wrote:
> Arne Vajhøj <arne@vajhoej.dk> writes:
>> Der er faktisk ofte en pæn forskel på SUN, IBM, BEA og Oracle
>> med hensyn til performance.
>
> Det er bare ikke nemt at hitte nogen konkrete oversigter over hvor
> forskellene ligger således at man på forhånd kan sige - hov, her var
> det måske en ide at overveje et JVM-skifte.
Rigtigt. Det kræver test. Men det fylder jo kun nogle få hundrede MB,
så man kan sagtens have et godt udvalg installeret til at teste.
> Vidste iøvrigt ikke Oracle havde deres egen JVM.
Jo. JDeveloper og AS (OC4J) kommer med en OJVM.
Arne
| |
Thorbjørn Ravn Ander~ (06-08-2007)
| Kommentar
Fra : Thorbjørn Ravn Ander~ |
Dato : 06-08-07 07:19 |
|
Arne Vajhøj <arne@vajhoej.dk> writes:
> Rigtigt. Det kræver test. Men det fylder jo kun nogle få hundrede MB,
> så man kan sagtens have et godt udvalg installeret til at teste.
Du undervurderer vist hvor lang tid det tager at hitte dem og
installere dem og holde dem ajour.
Nu kan du fx se jeg ikke vidste at Oracle havde en JVM - en hurtig
oversigt over dem og deres forcer havde sparet mig en MASSE tid.
Det er også mindre vigtigt i dette tilfælde - slutmaskinen har kun een
JVM - men til en anden god gang.
--
Thorbjørn Ravn Andersen
| |
Arne Vajhøj (06-08-2007)
| Kommentar
Fra : Arne Vajhøj |
Dato : 06-08-07 23:47 |
|
Thorbjørn Ravn Andersen wrote:
> Arne Vajhøj <arne@vajhoej.dk> writes:
>> Rigtigt. Det kræver test. Men det fylder jo kun nogle få hundrede MB,
>> så man kan sagtens have et godt udvalg installeret til at teste.
>
> Du undervurderer vist hvor lang tid det tager at hitte dem og
> installere dem og holde dem ajour.
Ah. Der kommer vel en ny Java version med ca. halvandet års mellemrum.
Hvis man f.eks. vil have SUN, BEA og IBM, så skal man derfor installere
i gennemsnit hver 6. måned. Det går nok.
> Nu kan du fx se jeg ikke vidste at Oracle havde en JVM - en hurtig
> oversigt over dem og deres forcer havde sparet mig en MASSE tid.
Jeg tror ikke at der findes en sådan liste. Jeg tror også at det vil
være en kollossal opgave at lave en liste.
Men hvis man har de JVM'er installeret og et program der er
"interessant" kan man jo hurtigt teste.
Arne
| |
Andreas Plesner Jaco~ (06-08-2007)
| Kommentar
Fra : Andreas Plesner Jaco~ |
Dato : 06-08-07 09:22 |
|
On 2007-08-06, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> Det er bare ikke nemt at hitte nogen konkrete oversigter over hvor
>> forskellene ligger således at man på forhånd kan sige - hov, her var
>> det måske en ide at overveje et JVM-skifte.
>
> Rigtigt. Det kræver test. Men det fylder jo kun nogle få hundrede MB,
> så man kan sagtens have et godt udvalg installeret til at teste.
Benchmarks er i øvrigt heller ikke nemme at lave (rigtigt første gang)
--
Andreas
| |
Arne Vajhøj (06-08-2007)
| Kommentar
Fra : Arne Vajhøj |
Dato : 06-08-07 23:48 |
|
Andreas Plesner Jacobsen wrote:
> On 2007-08-06, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> Det er bare ikke nemt at hitte nogen konkrete oversigter over hvor
>>> forskellene ligger således at man på forhånd kan sige - hov, her var
>>> det måske en ide at overveje et JVM-skifte.
>> Rigtigt. Det kræver test. Men det fylder jo kun nogle få hundrede MB,
>> så man kan sagtens have et godt udvalg installeret til at teste.
>
> Benchmarks er i øvrigt heller ikke nemme at lave (rigtigt første gang)
Den allerbedste benchmark er nem at lave.
Det er nemlig det program man faktisk skal køre.
Arne
| |
Andreas Plesner Jaco~ (15-08-2007)
| Kommentar
Fra : Andreas Plesner Jaco~ |
Dato : 15-08-07 10:24 |
|
On 2007-08-06, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> Benchmarks er i øvrigt heller ikke nemme at lave (rigtigt første gang)
>
> Den allerbedste benchmark er nem at lave.
>
> Det er nemlig det program man faktisk skal køre.
Det er en meget simplificeret forestilling du har til benchmarks.
De fleste programmer har eksterne afhængigheder, det være sig udstyr,
brugere eller andre programmer.
Som regel ønsker man at performe godt når man skalerer disse eksterne
afhængigheder, og det er netop det, der kan være vanskeligt at
benchmarke. Specielt når man begynder at blande låsning og concurrency
ind i billedet.
--
Andreas
| |
Arne Vajhøj (16-08-2007)
| Kommentar
Fra : Arne Vajhøj |
Dato : 16-08-07 02:21 |
|
Andreas Plesner Jacobsen wrote:
> On 2007-08-06, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> Benchmarks er i øvrigt heller ikke nemme at lave (rigtigt første gang)
>> Den allerbedste benchmark er nem at lave.
>>
>> Det er nemlig det program man faktisk skal køre.
>
> Det er en meget simplificeret forestilling du har til benchmarks.
> De fleste programmer har eksterne afhængigheder, det være sig udstyr,
> brugere eller andre programmer.
Brugere skal simuleres men udstyr og andre programmer
forefindes forhåbentligt også i test konfigurationen.
Arne
| |
|
|