---

Det ser ud til at der færdes folk herinde, der har styr på formler og
tal. (Hvad betyder ^?).

Det sidste års tid har jeg haft denne opløsnings-kalkulator liggende.
Jeg ville så gerne have den til at renge med højde bredde i cm...

- og så ville jeg så gerne have den til at angive vægt!!! - altså hvor
mange megabyte det aktuelle billede vejer ukomprimeret i CMYK 8 bit!!! -
kan man det - jeg kan ikke - er der nogen der kan?

<http://home19.inet.tele.dk/storms/ScanCalc.htm>

--
Venlig hilsen Nina Storm

---

> Det ser ud til at der færdes folk herinde, der har styr på formler og
> tal. (Hvad betyder ^?).

'^' betyder normalt 'opløftet i'
altså fx:
y=x^2
er det samme som:
y er lig med x i anden

capische?

---

tdn <merlin@sprex.dk> wrote:

> > Det ser ud til at der færdes folk herinde, der har styr på formler og
> > tal. (Hvad betyder ^?).
>
> '^' betyder normalt 'opløftet i'
> altså fx:
> y=x^2
> er det samme som:
> y er lig med x i anden
>
> capische?

Tak - det er forstået

--
Venlig hilsen Nina Storm

---

"Storm" sprang på tungen, og skrev:

| Det ser ud til at der færdes folk herinde, der har styr på formler
og
| tal. (Hvad betyder ^?).

Yeap, opløftet i x-potens.

| Det sidste års tid har jeg haft denne opløsnings-kalkulator
liggende.
| Jeg ville så gerne have den til at renge med højde bredde i cm...

Det letteste ville nok være at tilføje et felt hvor tomme værdierne
angives i cm. Hvor det skal tilføjes henne kan jeg dog ikke helt
gennemskue.
Som det er nu kan du jo bare hoppe ind i koden og tilføje en 2.54
multiplier alle de steder der nævnes inches (og hvor det er relevant
for dig). Dette gøres lettest ved at åbne i eks. notepad - lav dine
ændringer - og gem som htm/html igen (eller omdøb '.txt' til '.html').

| - og så ville jeg så gerne have den til at angive vægt!!! - altså
hvor
| mange megabyte det aktuelle billede vejer ukomprimeret i CMYK 8
| bit!!! - kan man det - jeg kan ikke - er der nogen der kan?

Det er igen bare et felt med en enkelt udregning der skal tilføjes.
Jeg er ikke helt sikker på hvordan man skal kæde formel definitionen
sammen med input i formen, men ellers må det være let nok.
Formlen er i øvrigt (pixels vertikalt*pixels horisontalt)*3 byte (8
bits pr byte og 3 byte pr pixel) = raw image bytes. Dette tal
dividerer du så med 1024 (eller 2^10) for at få Kbyte, eller 1048576
(2^20) for at få størrelse i Mbyte.

Hvis du eksempelvis scanner et 6x4 tommer portræt ind ved 200 PPI >
(6*200)x(4*200) = 1200x800 pixels, som ganget med hinanden =
1200*800px = 960000 px. 960000*3 byte = 2880000 bytes/1048576 = 2,74
Mbyte.

--
/Digit
011001011 <-- Sprej mi polykralpy?

---

Digit <no@no.no> wrote:

> Det letteste ville nok være at tilføje et felt hvor tomme værdierne
> angives i cm. Hvor det skal tilføjes henne kan jeg dog ikke helt
> gennemskue.

Jeg kan heller ikke, men der er sikkert nogle der vil synes det er alt
for let.

> Som det er nu kan du jo bare hoppe ind i koden og tilføje en 2.54
> multiplier alle de steder der nævnes inches (og hvor det er relevant
> for dig). Dette gøres lettest ved at åbne i eks. notepad - lav dine
> ændringer - og gem som htm/html igen (eller omdøb '.txt' til '.html').

Sådan kunne man selvfølgelig gøre det.
>
> | - og så ville jeg så gerne have den til at angive vægt!!! - altså hvor |
> mange megabyte det aktuelle billede vejer ukomprimeret i CMYK 8 | bit!!! -
> kan man det - jeg kan ikke - er der nogen der kan?
>
> Det er igen bare et felt med en enkelt udregning der skal tilføjes.
> Jeg er ikke helt sikker på hvordan man skal kæde formel definitionen
> sammen med input i formen,

Nej, sådan er jeg eller ikke vant til at regne.

> men ellers må det være let nok.
> Formlen er i øvrigt (pixels vertikalt*pixels horisontalt)*3 byte (8
> bits pr byte og 3 byte pr pixel) = raw image bytes.

3? - For hver kanal i rgb - og altså 4 for CMYK? eller?

> Dette tal
> dividerer du så med 1024 (eller 2^10) for at få Kbyte, eller 1048576
> (2^20) for at få størrelse i Mbyte.
>
> Hvis du eksempelvis scanner et 6x4 tommer portræt ind ved 200 PPI >
> (6*200)x(4*200) = 1200x800 pixels, som ganget med hinanden =
> 1200*800px = 960000 px. 960000*3 byte = 2880000 bytes/1048576 = 2,74
> Mbyte.

Tak, men desværre er jeg ikke istand til at sætte det ind i et script.
Det ville ihvertfald nok tage et par uger - med hjælp...

--
Venlig hilsen Nina Storm

---

"Storm" sprang på tungen, og skrev:

|| men ellers må det være let nok.
|| Formlen er i øvrigt (pixels vertikalt*pixels horisontalt)*3 byte (8
|| bits pr byte og 3 byte pr pixel) = raw image bytes.
|
| 3? - For hver kanal i rgb - og altså 4 for CMYK? eller?

Næeh, det må være det samme. CMY > tre værdier.

|| Hvis du eksempelvis scanner et 6x4 tommer portræt ind ved 200 PPI >
|| (6*200)x(4*200) = 1200x800 pixels, som ganget med hinanden =
|| 1200*800px = 960000 px. 960000*3 byte = 2880000 bytes/1048576 =
2,74
|| Mbyte.

| Tak, men desværre er jeg ikke istand til at sætte det ind i et
script.
| Det ville ihvertfald nok tage et par uger - med hjælp...

Hvis ingen andre melder sig er jeg frisk på at prøve... det ville bare
være at foretrække med én som lige "mumbo-jumpo mumbo-jumpo" kan ordne
sagerne ;)

--
/Digit
011001011 <-- Sprej mi polykralpy?

---

On Thu, 12 Sep 2002 17:23:27 +0200, "Digit" <no@no.no> wrote:


>Næeh, det må være det samme. CMY > tre værdier.

Du mangler K = fire

Det kan regnes ud i Photoshop. Æble-N og tast bredde og højde ind, så
har man størrelsen i MB. Det bruger jeg selv.

--

Med venlig hilsen
Kurt Brixen

---

"Kurt Brixen" sprang på tungen, og skrev:

|| Næeh, det må være det samme. CMY > tre værdier.
|
| Du mangler K = fire

Det var bevidst. På video arbejder du jo i RGB; CMYK eller ej så vil
din skærm stadig vise via Rød Grøn Blå. Selve konverteringen må være
softwaremæssigt (tror jeg da). Men sammenhængen tør jeg ikke udtale
mig om.

| Det kan regnes ud i Photoshop. Æble-N og tast bredde og højde ind,
så
| har man størrelsen i MB. Det bruger jeg selv.

Ja det virker fint. Brugte den også lige selv for at afprøve CMYK <>
RGB.

--
/Digit
011001011 <-- Sprej mi polykralpy?

---

"Digit" <no@no.no>
>
> || Næeh, det må være det samme. CMY > tre værdier.
> |
> | Du mangler K = fire
>
> Det var bevidst. På video arbejder du jo i RGB; CMYK eller ej så vil
> din skærm stadig vise via Rød Grøn Blå. Selve konverteringen må være
> softwaremæssigt (tror jeg da). Men sammenhængen tør jeg ikke udtale
> mig om.
>
> | Det kan regnes ud i Photoshop. Æble-N og tast bredde og højde ind,
> så
> | har man størrelsen i MB. Det bruger jeg selv.
>
> Ja det virker fint. Brugte den også lige selv for at afprøve CMYK <>
> RGB.

Min ide var et værktøj til folk der ikke ved så meget om det tekniske
eller digitale, men modtager nogle billeder, som de kunne få en
fornemmelse af, i hvilken størrelse de kan anvendes til f.eks.
magasintryk, bare ved at se hvor meget de fylder. Eller hvor meget ca.
det skal fylde (veje) for at kunne trykkes på f.eks. en hel A4 side.
Ja, ja - en masse forbehold - men en fornemmelse. - Også folk der
ikke har Photoshop på deres maskine.

Det ville være fedt hvis en var frisk til "mumbo-jumpo mumbo-jumpo" at
smække det ind i den html jeg smed i linket.
Det kunne flere måske bruge til noget

- Først nu tjekkede jeg lige Madsens link.
Og Madsen helt ærligt - det er jo lige det. Har du haft det liggende længe,
eller er du bare flyvende på googlen?
Udregningerne bagved ser meget komplicerede ud, men brugerfladen er
da dejlig enkel.

--
Venlig hilsen Nina

---

Storm wrote:

>
>
> - Først nu tjekkede jeg lige Madsens link.
> Og Madsen helt ærligt - det er jo lige det. Har du haft det liggende længe,
> eller er du bare flyvende på googlen?
> Udregningerne bagved ser meget komplicerede ud, men brugerfladen er
> da dejlig enkel.

Ja. men den holder ikke i retten.
Prøv at lave et nyt dokument i Photoshop 13 Bx 18 H cm, CMYK farver, opløsning
150 pixel/tomme (til avisbrug med 100 LPI /40 L CM)
Filen vil så fylde 3,12 MB
Indtast de samme værdier i calculatoren med output på 100 ppi så bliver
resultatet 9.36 mb i CMYK
Bruger du 150 ppi er resultatet 21.06 mb

Derimod er din Calculator meget fin. Den kan skam bruges med cm som den er -
udregningsfaktoren er den samme - man kan bare lege at der står cm - istedet
for inch.

Den kunne et (anonymt) reklamebureau have haft god brug for.
I går modtog jeg en CD med en Matas annonce for Revlon kosmetik, indeholdene
et Quark dokument et par logoer og 2 indscannede CMYK billeder.
Det ene 4 cm bred og 2 cm høj fyldte 46,5 MB = indscannet i 1200 DPI - efter
ændring til 150 DPI fylder det 104 KB
Det andet ca A4 størrelse - indscannet i 600 DPI fyldte 215,6 MB - efter
ændring til 150 DPI og reducering til 13 cm bred fylder det 3.91 MB
Jeg gad nok vide hvilken trykmaskine der har brug for 1200/600 DPI - selv en
fotoprinter (hos fotografen) bruger kun 300 DPI.

--
Venlig hilsen
Villy Erichsen
Fjern *not* for at svare på mail.

---

Villy Erichsen <brita-villy@adslhome.dk> wrote:

> Ja. men den holder ikke i retten.
> Prøv at lave et nyt dokument i Photoshop 13 Bx 18 H cm, CMYK farver, opløsning
> 150 pixel/tomme (til avisbrug med 100 LPI /40 L CM)
> Filen vil så fylde 3,12 MB
> Indtast de samme værdier i calculatoren med output på 100 ppi så bliver
> resultatet 9.36 mb i CMYK
> Bruger du 150 ppi er resultatet 21.06 mb

Øv, jeg har ikke tid til eksperimenter i dag. Det så ellers så godt ud.


> Derimod er din Calculator meget fin. Den kan skam bruges med cm som den er -
> udregningsfaktoren er den samme - man kan bare lege at der står cm - istedet
> for inch.

<http://home19.inet.tele.dk/storms/Calc_cm_.htm>

> Den kunne et (anonymt) reklamebureau have haft god brug for.
> I går modtog jeg en CD med en Matas annonce for Revlon kosmetik, indeholdene
> et Quark dokument et par logoer og 2 indscannede CMYK billeder.
> Det ene 4 cm bred og 2 cm høj fyldte 46,5 MB = indscannet i 1200 DPI - efter
> ændring til 150 DPI fylder det 104 KB
> Det andet ca A4 størrelse - indscannet i 600 DPI fyldte 215,6 MB - efter
> ændring til 150 DPI og reducering til 13 cm bred fylder det 3.91 MB
> Jeg gad nok vide hvilken trykmaskine der har brug for 1200/600 DPI - selv en
> fotoprinter (hos fotografen) bruger kun 300 DPI.

Sidst brugte de det måske til en husfacade i Høje Gladsaxe
Hvis logoet er i 1200 ppi er der måske nogen der har tænkt, at når det
ikke er en vektor, og ikke er streg (bitmap) må de hellere levere
Cmyk-logen i 1200 ppi?
Men pas på - herinde er der hede debatter om ad adskille dpi og ppi
begreberne
--
Venlig hilsen Nina Storm

---

Storm wrote:

> Villy Erichsen <brita-villy@adslhome.dk> wrote:
>
> > Ja. men den holder ikke i retten.
> > Prøv at lave et nyt dokument i Photoshop 13 Bx 18 H cm, CMYK farver, opløsning
> > 150 pixel/tomme (til avisbrug med 100 LPI /40 L CM)
> > Filen vil så fylde 3,12 MB
> > Indtast de samme værdier i calculatoren med output på 100 ppi så bliver
> > resultatet 9.36 mb i CMYK
> > Bruger du 150 ppi er resultatet 21.06 mb
>
> Øv, jeg har ikke tid til eksperimenter i dag. Det så ellers så godt ud.

Det vil i den sammenhæng nok også være spild af tid.
Vægten af et billede kan ikke bruges til noget som helst - f. eks. kan et EPS
billede være JPEG kodet og dermed fylde væsentligt mindre.
Metoden bruges ofte af firmaer der lægger deres billeder på nettet til brug for
aviser m. v.
Hvis man kender noget til værdien af et billeds vægt har man sandsynligvis også
Photoshop eller lign. og programmerne kan bedre end noget andet fortælle om
billedets kvalitet.

--
Venlig hilsen
Villy Erichsen
Fjern *not* for at svare på mail.

---

Villy Erichsen <brita-villy@adslhome.dk> wrote:

> Vægten af et billede kan ikke bruges til noget som helst - f. eks. kan et
> EPS billede være JPEG kodet og dermed fylde væsentligt mindre. Metoden
> bruges ofte af firmaer der lægger deres billeder på nettet til brug for
> aviser m. v.

Jo, det er jeg klar over. Et tif billede kan også jpg komprimeres i dag,
ihvertfald fra Photoshop 7.

> Hvis man kender noget til værdien af et billeds vægt har man sandsynligvis
> også Photoshop eller lign. og programmerne kan bedre end noget andet
> fortælle om billedets kvalitet.

Du har nok ret. Vægten kan kun bruges af folk der ved hvad det handler
om og som kan tjekke om billedet er komprimeret eller ej.

Endelig kan et billede måske udmærket bruges til et bestemt formål selv
om det kun fylder det halve af hvad det ville gøre "matematisk" uden
komprimering.

Eks.: Et tiff billede på 38 mega i 300 ppi RGB indeholder store sorte
flader og få lyse tegninger. Det jpg komprimeres, og fylder som jpg i
højeste kvalitets kompression ca. 2 mega. Det åbnes og gemmes ned i tiff
igen. Resultat: billedet fylder kun 18 mega, men du kan først i 300% kun
ane forringelserne. Med et andet billede kunne resultatet meget vel have
været helt anderledes.

Ideen kunne nok kun fungere i en verden hvor ingen komprimerede
billederne, og sådan en verden færdes ingen af os i...

-- Venlig hilsen Nina Storm

---

"Villy Erichsen" sprang på tungen, og skrev:

| Det vil i den sammenhæng nok også være spild af tid.

Jeg går ud fra at Storm ønsker at bruge oplysningerne til scannerjobs.
I så fald kan det være ret så vigtigt at kunne regne ud "on the fly"
hvor meget ens scanning kommer til at fylde.

--
/Digit
011001011 <-- Sprej mi polykralpy?

---

Digit wrote:

> "Villy Erichsen" sprang på tungen, og skrev:
>
> | Det vil i den sammenhæng nok også være spild af tid.
>
> Jeg går ud fra at Storm ønsker at bruge oplysningerne til scannerjobs.
> I så fald kan det være ret så vigtigt at kunne regne ud "on the fly"
> hvor meget ens scanning kommer til at fylde.
>

Det fortæller de fleste scannerprogrammer når billedfeltet er valgt.

--
Venlig hilsen
Villy Erichsen
Fjern *not* for at svare på mail.

---

"Villy Erichsen" <brita-villy@adslhome.dk> skrev

> > Jeg går ud fra at Storm ønsker at bruge oplysningerne til scannerjobs.
> > I så fald kan det være ret så vigtigt at kunne regne ud "on the fly"
> > hvor meget ens scanning kommer til at fylde.
> >
>
> Det fortæller de fleste scannerprogrammer når billedfeltet er valgt.

Jo, det var heller ikke ideen, men som jeg skrev:

"...et værktøj til folk der ikke ved så meget om det tekniske
eller digitale, men modtager nogle billeder, som de kunne få en
fornemmelse af, i hvilken størrelse de kan anvendes til f.eks.
magasintryk, bare ved at se hvor meget de fylder. Eller hvor meget ca.
det skal fylde (veje) for at kunne trykkes på f.eks. en hel A4 side.
Ja, ja - en masse forbehold - men en fornemmelse. - Også folk der
ikke har Photoshop på deres maskine..."

Jeg har haft det liggende i baghovedet, som noget jeg gerne ville
lave et godt stykke tid. Men i virkelighedens verden er den ca.
oversigt jeg har over størrelsen på ukomprimerede CMYK tif
billeder i 5-6 standardformater vist lige så god (eller uanvendelig
til formålet).
Det typiske scenaria er jo, at folk sender jpg-rgb eller andet, hvor
det kræver, at man med Photoshop eller andet går ind og tjekker
billedets kvalitet og muligheder.
Vi skal jo vise vores faglige uundværlighed.

Ideen er droppet - men jeg fik vist ro i sjælen - ang. _den_ idé

--
Venlig hilsen Nina

---

Storm wrote:

>
> <http://home19.inet.tele.dk/storms/Calc_cm_.htm>

Man kunne jo også lave den på dansk

http://www.hammel-nyt.dk/pages/scanudregn.html


--
Venlig hilsen
Villy Erichsen
Fjern *not* for at svare på mail.

---

"Villy Erichsen" sprang på tungen, og skrev:

|| - Først nu tjekkede jeg lige Madsens link.
|| Og Madsen helt ærligt - det er jo lige det. Har du haft det
liggende
|| længe, eller er du bare flyvende på googlen?
|| Udregningerne bagved ser meget komplicerede ud, men brugerfladen er
|| da dejlig enkel.

| Ja. men den holder ikke i retten.
| Prøv at lave et nyt dokument i Photoshop 13 Bx 18 H cm, CMYK farver,
| opløsning 150 pixel/tomme (til avisbrug med 100 LPI /40 L CM)
| Filen vil så fylde 3,12 MB
| Indtast de samme værdier i calculatoren med output på 100 ppi så
| bliver resultatet 9.36 mb i CMYK
| Bruger du 150 ppi er resultatet 21.06 mb

Det er lige gået op for mig at vi i denne tråd har antaget megabytes
er 1000*1000=1e6 bytes, hvilket jo er forkert eftersom
1024x1024=1.048.576 bytes (2^10*2^10). Så Madsens form kalkulator
regner skam rigtigt -- den viser bare resultatet i millioner bytes og
ikke megabytes.

Det må næsten være en fejl.

--
/Digit
011001011 <-- Sprej mi polykralpy?

---

Kurt Brixen wrote:
> Æble-N og tast bredde og højde ind, så har man størrelsen i MB.

Hvorfor blande frugt ind i snakken? CTRL+N fungerer fint som
genvejstaster.







--
Med venlig hilsen
Kim Jensen
____________________________________________
litewerx.com // kelvin8.com // newscaster.dk

---

Digit skrev:

>| 3? - For hver kanal i rgb - og altså 4 for CMYK? eller?
>
> Næeh, det må være det samme. CMY > tre værdier.

Det vil jeg nu ikke mene at det er:
http://www.ivan.co.nz/FileSzCalc.htm

--
Med venlig hilsen
Madsen.

---

"Madsen" sprang på tungen, og skrev:

||| 3? - For hver kanal i rgb - og altså 4 for CMYK? eller?
||
|| Næeh, det må være det samme. CMY > tre værdier.

| Det vil jeg nu ikke mene at det er:
| http://www.ivan.co.nz/FileSzCalc.htm

Du har ret. Jeg har selv lige afprøvet med i photoshop, og CMYK fylder
en del mere.
Har lige "brækket" hans udregning itu, og selve CMYK filesize feltet
bruger
<form.payment.value=((form.months.value*form.rate.value*(form.financed
..value*form.financed.value)*3)/1000000);> hvor months.value er [højde,
inch], rate.value [bredde, inch] og financed.value [opløsning PPI].
Simplificeret ser fomlen sådan her ud:
((height*width)*(resolution^2)*3)/1e6.
Forskellen er at produktet efter parantes divideres med 1000000 (og
ikke 1048576). Gad vide hvorfor??

Om jeg fatter hans benævnelser af felterne. Eg. payment.value
financed.value etc. Meget mystik ;)

--
/Digit
011001011 <-- Sprej mi polykralpy?

---

Digit skrev:

> Om jeg fatter hans benævnelser af felterne. Eg. payment.value
> financed.value etc. Meget mystik ;)

Ja, det har du egentlig ret i.

--
Med venlig hilsen
Madsen.

---

Storm skrev:

> Det ville være fedt hvis en var frisk til "mumbo-jumpo
> mumbo-jumpo" at smække det ind i den html jeg smed i linket.
> Det kunne flere måske bruge til noget

Jeg ville gerne gøre det hvis jeg kunne, men aner ikke en hujende
fis om HTML og kan ikke gennemskue hvordan den er skruet sammen
og det hverken den du har sendt eller den jeg har sendt i denne
tråd. Kan godt regne ud hvor meget en fil vil komme til at fylde
ukomprimeret, men at lave en side i HTML som kan udregne det, har
jeg intet begreb om desværre.

> Og Madsen helt ærligt - det er jo lige det. Har du haft det
> liggende længe, eller er du bare flyvende på googlen?

Det var en søgning på google der fandt den. Har ikke søgt på noget
lignende tidligere, men kan godt huske at du har efterlyst det
tidligere. Søgningen er her: http://makeashorterlink.com/?P3BC124C1

> Udregningerne bagved ser meget komplicerede ud, men brugerfladen
> er da dejlig enkel.

Ja, den er da til at gå til. Det behøver jo heller ikke at være
særlig fancy. :)

--
Med venlig hilsen
Madsen.

---

Villy Erichsen skrev:

[http://www.ivan.co.nz/FileSzCalc.htm]

> Ja. men den holder ikke i retten.

Nej, det har du nu vist ret i. Efter at have prøvet dit eksempel
kan jeg godt se at den rammer en del ved siden af. Den skulle man
vist lige have rodet med lidt længere inden man kastede den ud til
masserne. :)

> Derimod er din Calculator meget fin. Den kan skam bruges med cm
> som den er - udregningsfaktoren er den samme - man kan bare lege
> at der står cm - istedet for inch.

Det er rigtigt og at rette til centimeter i stedet kan selv jeg
finde ud af <http://home18.inet.tele.dk/madsen/scancalc.htm>
- men derfra og så til at integrere en "vægt-måler" er der et
stykke vej. :)

--
Med venlig hilsen
Madsen.