Welche Tiff-Komprimierung mit convert (Imagemagick) f. Aftershot Pro?

[А. Воgnеr]

Scan mit Vuescan:
scan0001.tif: 9,1M
[EXIF] 0x0103 Compression : Uncompressed

http://www.hamrick.com/vuescan/html/vuesc32.htm#outputtiffcompression
The default setting is "Auto", which enables compression for files with
12 or fewer bits per sample and disables compression for files more
bits per sample.

Was gibt es für Gründe nicht automatisch zu komprimieren?


convert scan0001.tif -quality 95 scan0001.tif.png
Für die, die convert nicht kennen, "quality" bezieht sich auf die
Kompressionsmethode
7,3M

convert scan0001.tif.png scan0001auspng.tif
7,5M
[EXIF] 0x0103 Compression : Adobe Deflate

http://www.imagemagick.org/script/command-line-options.php#compress

-compress type

Use pixel compression specified by type when writing the image.
Choices are: None, BZip, Fax, Group4, JPEG, JPEG2000, Lossless, LZW,
RLE or Zip.

So wie es aussieht bezieht sich das aber nicht auf die
Tiff-Komprimierung, denn ich erhalte mit

convert scan0001.tif.png -compress BZip scan0001auspng_bzip.tif
[EXIF] 0x0103 Compression : Uncompressed
9,2M

Gibt es da eine besser Tiff-Komprimierung als die Standardkomprimierung?


--
Αl

[А. Воgnеr]

Ich habe weiter getestet und dabei herausgefunden, dass die beste
Komprimierung "-compress zip" ist, und manche
Komprimierungsmöglichkeiten schlicht nicht wirken. "-compress zip"
ergibt mit exiftool "Adobe Deflate" und warum das manchmal ohne Angabe
einer Komprimierungsart verwendet wird, ist mir nicht klar geworden.

Noch besser komprimiert aber png.

Bei der Wandlung dürfte nichts verloren gehen, wenn man die Dateigrößen
betrachtet

Vuescan-Scan unkomprimiert, 600dpi, 16bit:
test_uncompressed.tif: 5854691

convert test_uncompressed.tif -compress zip
test_uncompressed.zip.tif: 2520553

convert test_uncompressed.tif -quality 95 (90 und 95 ergeben die beste
und gleiche Komprimierung)
test_uncompressed_q95.png: 2062593

Als Test, ob was verlorengegangen ist:
convert test_uncompressed_q95.png -compress zip
test_uncompressed.png.tif: 2520553

Die Bytes der beiden Dateien sind also bei test_uncompressed.zip.tif und
test_uncompressed.png.tif ident und wurden auf unterschiedliche Weise
erzeugt.

identify -verbose test_uncompressed.zip.tif
Geometry: 1443x2028+0+0
Resolution: 600x600
Print size: 2.405x3.38
Colorspace: RGB
Depth: 16-bit
Channel depth:
gray: 16-bit
Channel statistics:
Gray:
min: 12760 (0.194705)
max: 65535 (1)
mean: 41315.7 (0.630437)
standard deviation: 16418 (0.250523)
kurtosis: -1.34544
skewness: 0.170723
Compression: Zip
Filesize: 2.521MBB
Number pixels: 2.926MB


identify -verbose test_uncompressed_q95.png
Geometry: 1443x2028+0+0
Resolution: 236.22x236.22
Print size: 6.10871x8.58522
Colorspace: Gray
Depth: 16-bit
Channel depth:
gray: 16-bit
Channel statistics:
Gray:
min: 12760 (0.194705)
max: 65535 (1)
mean: 41315.7 (0.630437)
standard deviation: 16418 (0.250523)
kurtosis: -1.34544
skewness: 0.170723
Colormap: 65536
Compression: Zip
Filesize: 2.063MBB
Number pixels: 2.926MB

So ganz klar ist mir nicht, warum eine unterschiedliche "Resolution"
bei gleicher "Geometry" angegeben wird, die dann logischerweise zu einer
unterschiedlichen Druckgröße führt.

Grob kann bei SW also gegenüber einem unkomprimierten TIF 2/3 des
Speicherplatzes sparen und da lohnt es sich schon näher über den
gesamten Workflow nachzudenken

Leider können alle Dateien von Aftershot Pro nicht gelesen werden, die
mit Vuescan als Input SW gescannt werden. Aftershot ladet nur Dateien,
die sowohl Input als auch Output Farbe haben und das kostet natürlich
extrem Speicherplatz.

Jedoch kann Darktable diese TIFF bzw. PNG-Dateien lesen.

Interessant ist auch, dass Gimp die TIFF-Datei nach 8bit umwandelt, die
PNG-Datei, ebenfalls 16-bit grey, aber nicht. Zur Bearbeitung denke ich,
ist aber ein Programm, das die Veränderung in einer xmp-Datei beschreibt
und das Original unberührt lässt die bessere Wahl.




--
Αl

[Wolfgang Weisselberg]

А Воgnеr <noreply-address-del...@corr.eu.org> wrote:

> Use pixel compression specified by type when writing the image.
> Choices are: None, BZip, Fax, Group4, JPEG, JPEG2000, Lossless, LZW,
> RLE or Zip.

> So wie es aussieht bezieht sich das aber nicht auf die
> Tiff-Komprimierung, denn ich erhalte mit

> convert scan0001.tif.png -compress BZip scan0001auspng_bzip.tif
> [EXIF] 0x0103 Compression : Uncompressed
> 9,2M

> Gibt es da eine besser Tiff-Komprimierung als die Standardkomprimierung?

BZip ist eben keine erlaubte Komprimierung für TIFF.
Interessant für Farbbilder sind unkomprimiert, PackBits und LZW
(geg. mit Predictor).

Dann noch (aber nicht im Baseline TIFF, d.h. das zu können
ist ganz optional):
- JPEG/JPEG lossless für Grayscale, RGB, CMYK, YCrCb
- Deflate aka Zip (geg. mit Predictor)

JPEG lossy ist wohl die am stärksten komprimierende
TIFF-Komprimierung, aber selbst wenn der Leser TIFF-JPEG lesen
kann, heißt das nicht, daß er jedes TIFF-JPEG kann.


http://partners.adobe.com/public/developer/tiff/index.html#spec

-Wolfgang

[Bernd Mayer]

Am 10.04.2013 16:55, schrieb А. Воgnеr:
> Scan mit Vuescan:
> scan0001.tif: 9,1M
> [EXIF] 0x0103 Compression : Uncompressed
>
> http://www.hamrick.com/vuescan/html/vuesc32.htm#outputtiffcompression
> The default setting is "Auto", which enables compression for files with
> 12 or fewer bits per sample and disables compression for files more
> bits per sample.
>
> Was gibt es für Gründe nicht automatisch zu komprimieren?

Hallo,

Kompatibilität.

Siehe z.B.: http://de.wikipedia.org/wiki/Tagged_Image_File_Format

"Größter Nachteil von TIFF ist seine Komplexität. Die Vielfalt möglicher
gültiger TIFF-Dateien kann nur schwer von einzelnen Programmen
unterstützt werden. In der Spezifikation des Dateiformates ist deswegen
eine Untermenge gültiger TIFF-Dateien definiert, die jedes TIFF-fähige
Programm verarbeiten können sollte, genannt Baseline TIFF."

Oder auch die SPECs: http://www.awaresystems.be/imaging/tiff/faq.html


Bernd Mayer

[Wolfgang Weisselberg]

А Воgnеr <noreply-address-del...@corr.eu.org> wrote:
> Am Mi, 10 Apr 2013 16:55:09 CEST schrieb А. Воgnеr:

> Ich habe weiter getestet und dabei herausgefunden, dass die beste
> Komprimierung "-compress zip" ist, und manche
> Komprimierungsmöglichkeiten schlicht nicht wirken. "-compress zip"
> ergibt mit exiftool "Adobe Deflate" und warum das manchmal ohne Angabe
> einer Komprimierungsart verwendet wird, ist mir nicht klar geworden.

Deflate *ist* eine Komprimierungsart.

> Noch besser komprimiert aber png.

Ja. Und?

> Bei der Wandlung dürfte nichts verloren gehen, wenn man die Dateigrößen
> betrachtet

Ob 2 Bilder visuell abweichen, kann man z.B. mit einer Differenz
zwischen 2 Layern in Gimp oder mit der Blink-Methode visuell
feststellen.

> Geometry: 1443x2028+0+0
> Resolution: 600x600
> Print size: 2.405x3.38

> Geometry: 1443x2028+0+0
> Resolution: 236.22x236.22
> Print size: 6.10871x8.58522

> So ganz klar ist mir nicht, warum eine unterschiedliche "Resolution"
> bei gleicher "Geometry" angegeben wird, die dann logischerweise zu einer
> unterschiedlichen Druckgröße führt.

'dpi'. Korrekter: ppi.

> Leider können alle Dateien von Aftershot Pro nicht gelesen werden, die
> mit Vuescan als Input SW gescannt werden. Aftershot ladet nur Dateien,
> die sowohl Input als auch Output Farbe haben und das kostet natürlich
> extrem Speicherplatz.

ASP ist ein Kamera-Rohdaten-Bearbeitungs-Programm.

> Interessant ist auch, dass Gimp die TIFF-Datei nach 8bit umwandelt,

... ist halt noch nicht Gimp 2.10. Das soll dann 16 und 32
bit können.

-Wolfgang

[А. Воgnеr]

Am Mo, 15 Apr 2013 23:52:22 CEST schrieb Wolfgang Weisselberg:

> А Воgnеr <noreply-address-del...@corr.eu.org> wrote:
> > Am Mi, 10 Apr 2013 16:55:09 CEST schrieb А. Воgnеr:
>
> > Ich habe weiter getestet und dabei herausgefunden, dass die beste
> > Komprimierung "-compress zip" ist, und manche
> > Komprimierungsmöglichkeiten schlicht nicht wirken. "-compress zip"
> > ergibt mit exiftool "Adobe Deflate" und warum das manchmal ohne
> > Angabe einer Komprimierungsart verwendet wird, ist mir nicht klar
> > geworden.
>
> Deflate *ist* eine Komprimierungsart.

Klar, ich habe mich nur gewundert warum die manchmal verwendet wurde,
ohne, dass ich explizit compress angegeben hatte.

> > Noch besser komprimiert aber png.
>
> Ja. Und?

Somit könnte es eine Überlegung sein um Speicherplatz zu sparen von tif
nach png zu wandeln. Das kann HDs (inkl. Sicherungen) sparen.
Voraussetzung ist natürlich, dass man ein Programm hat, dass png
bearbeiten kann. Darktable kann mit png umgehen.

> > Bei der Wandlung dürfte nichts verloren gehen, wenn man die
> > Dateigrößen betrachtet
>
> Ob 2 Bilder visuell abweichen, kann man z.B. mit einer Differenz
> zwischen 2 Layern in Gimp oder mit der Blink-Methode visuell
> feststellen.
>
> > Geometry: 1443x2028+0+0
> > Resolution: 600x600
> > Print size: 2.405x3.38
>
> > Geometry: 1443x2028+0+0
> > Resolution: 236.22x236.22
> > Print size: 6.10871x8.58522
>
> > So ganz klar ist mir nicht, warum eine unterschiedliche "Resolution"
> > bei gleicher "Geometry" angegeben wird, die dann logischerweise zu
> > einer unterschiedlichen Druckgröße führt.
>
> 'dpi'. Korrekter: ppi.
>
> > Leider können alle Dateien von Aftershot Pro nicht gelesen werden,
> > die mit Vuescan als Input SW gescannt werden. Aftershot ladet nur
> > Dateien, die sowohl Input als auch Output Farbe haben und das
> > kostet natürlich extrem Speicherplatz.
>
> ASP ist ein Kamera-Rohdaten-Bearbeitungs-Programm.

Nicht nur, es kann auch jpg und manche tif bearbeiten.

> > Interessant ist auch, dass Gimp die TIFF-Datei nach 8bit umwandelt,
>
> ... ist halt noch nicht Gimp 2.10. Das soll dann 16 und 32
> bit können.

Interessant war, dass gimp 2.6.12-1ubuntu1.2 16bit grey als png
akzeptiert, aber tif zu 8bit wandelt und dass ein neueres gimp unter
Opensuse 12.2 mehr Probleme machte.



--
Αl

[Wolfgang Weisselberg]

А Воgnеr <noreply-address-del...@corr.eu.org> wrote:
> Am Mo, 15 Apr 2013 23:52:22 CEST schrieb Wolfgang Weisselberg:
>> А Воgnеr <noreply-address-del...@corr.eu.org> wrote:

>> > Noch besser komprimiert aber png.

>> Ja. Und?

> Somit könnte es eine Überlegung sein um Speicherplatz zu sparen von tif
> nach png zu wandeln. Das kann HDs (inkl. Sicherungen) sparen.

TIFF mit JPEG-Encoding komprimiert vermutlich noch besser.

> Voraussetzung ist natürlich, dass man ein Programm hat, dass png
> bearbeiten kann.

Vorher in was anderes umwandeln können, das geht, reicht.

[...]

>> ASP ist ein Kamera-Rohdaten-Bearbeitungs-Programm.

> Nicht nur, es kann auch jpg und manche tif bearbeiten.

Man kann mit einem Auto auch fliegen --- z.B. hinter einer
Rampe oder eine Klippe runter ...

-Wolfgang

[Erich Brandt]

Am 17.04.2013 22:14, schrieb Wolfgang Weisselberg:
>>> ASP ist ein Kamera-Rohdaten-Bearbeitungs-Programm.
>
>> Nicht nur, es kann auch jpg und manche tif bearbeiten.
>
> Man kann mit einem Auto auch fliegen --- z.B. hinter einer
> Rampe oder eine Klippe runter ...

Was stört Dich daran, daß ein Rawdaten-Konverter neben diversen Raws
zusätzlich einige andere Dateiformate bearbeiten kann - ebenso
verlustlos wie die Raw-Dateien?

Ciao, Erich

[А. Воgnеr]

Am Mi, 17 Apr 2013 22:14:28 CEST schrieb Wolfgang Weisselberg:

> А Воgnеr <noreply-address-del...@corr.eu.org> wrote:
> > Am Mo, 15 Apr 2013 23:52:22 CEST schrieb Wolfgang Weisselberg:
> >> А Воgnеr <noreply-address-del...@corr.eu.org>
> >> wrote:
>
> >> > Noch besser komprimiert aber png.
>
> >> Ja. Und?
>
> > Somit könnte es eine Überlegung sein um Speicherplatz zu sparen von
> > tif nach png zu wandeln. Das kann HDs (inkl. Sicherungen) sparen.
>
> TIFF mit JPEG-Encoding komprimiert vermutlich noch besser.

Ich hatte alles mit einem Scan durchprobiert und png war am besten, aber
nun sehe ich bei einem Test mit einer jpg-datei, die aus einem RAW von
einer DSLR erstell wurde:

14M test.jpg
44M test.jpg2000.tif
21M test.jpg.tif
31M test.lzw.tif
31M test.png
26M test.zip.tif

Ich zweifle etwas, ob dieses test.jpg.tif verlustlos ist und prüfe.

Ich stelle gerade fest, identify -verbose zeigt nicht mehr die Anzahl
der Farben an.

Ich bin mir nicht sicher, ob es eine Möglichkeit ist damit zu
vergleichen, ob die Bilder ident sind.

convert test.jpg -define histogram:unique-colors=true -format %c \
histogram:info:- | wc -l
738677

convert test.jpg2000.tif -define histogram:unique-colors=true -format \
%c histogram:info:- | wc -l
738677

convert test.jpg.tif -define histogram:unique-colors=true -format %c \
histogram:info:- | wc -l
1704021
Hmmh, da ist ein Unterschied. Ist das jetzt im Vergleich zu den anderen
Komprimierungsmethoden nicht verlustlos?

convert test.lzw.tif -define histogram:unique-colors=true -format %c \
histogram:info:- | wc -l
738677

convert test.png -define histogram:unique-colors=true -format %c \
histogram:info:- | wc -l
738677

convert test.zip.tif -define histogram:unique-colors=true -format %c \
histogram:info:- | wc -l
738677


Vergleich 2er Dateien bzgl. der am häufigsten vorkommenden Farben:

convert test.zip.tif -define histogram:unique-colors=true -format %c \
histogram:info:- | sort -n
...
17628: ( 5, 13, 2) #050D02 rgb(5,13,2)
19403: ( 4, 11, 3) #040B03 rgb(4,11,3)
20043: ( 1, 3, 0) #010300 rgb(1,3,0)
22713: ( 1, 6, 0) #010600 rgb(1,6,0)
23960: ( 4, 9, 2) #040902 rgb(4,9,2)
30911: ( 3, 8, 2) #030802 rgb(3,8,2)
32739: ( 3, 5, 2) #030502 rgb(3,5,2)
41003: ( 2, 7, 1) #020701 rgb(2,7,1)
47162: ( 2, 4, 1) #020401 rgb(2,4,1)
55561: (253,254,249) #FDFEF9 rgb(253,254,249)

convert test.jpg.tif -define histogram:unique-colors=true -format %c \
histogram:info:- | sort -n
...
11536: ( 4, 3, 11) #04030B rgb(4,3,11)
12156: ( 3, 1, 8) #030108 rgb(3,1,8)
15603: ( 1, 0, 6) #010006 rgb(1,0,6)
15694: ( 4, 2, 9) #040209 rgb(4,2,9)
16309: ( 1, 0, 3) #010003 rgb(1,0,3)
20434: ( 3, 2, 5) #030205 rgb(3,2,5)
21159: ( 3, 2, 8) #030208 rgb(3,2,8)
28714: ( 2, 1, 7) #020107 rgb(2,1,7)
35279: ( 2, 1, 4) #020104 rgb(2,1,4)
53421: (253,249,254) #FDF9FE rgb(253,249,254)

> > Voraussetzung ist natürlich, dass man ein Programm hat, dass png
> > bearbeiten kann.
>
> Vorher in was anderes umwandeln können, das geht, reicht.

Grundsätzlich ja, kann aber ein organisatorisches Problem sein, optimal
wäre 1 verlustlose Datei, die möglichst klein ist.

> [...]
> >> ASP ist ein Kamera-Rohdaten-Bearbeitungs-Programm.
>
> > Nicht nur, es kann auch jpg und manche tif bearbeiten.
>
> Man kann mit einem Auto auch fliegen --- z.B. hinter einer
> Rampe oder eine Klippe runter ...

Ja schön, es geht aber um Ergebnisse. Was schlägst du zur Bearbeitung
eines Scans für ein Programm vor, das die Bearbeitung zB in einer
xmp-Datei speichert ähnlich Darktable. Das Original soll also
unverändert bleiben und die Bearbeitung später veränderbar sein, ohne,
dass komplett von vorne begonnen wird.




--
Αl

[Bernd Mayer]

Am 18.04.2013 23:24, schrieb А. Воgnеr:
>
> Ich hatte alles mit einem Scan durchprobiert und png war am besten, aber
> nun sehe ich bei einem Test mit einer jpg-datei, die aus einem RAW von
> einer DSLR erstell wurde:
>
> 14M test.jpg
> 44M test.jpg2000.tif
> 21M test.jpg.tif
>

> Ich zweifle etwas, ob dieses test.jpg.tif verlustlos ist und prüfe.
>
> Ich stelle gerade fest, identify -verbose zeigt nicht mehr die Anzahl
> der Farben an.

Hallo,

und was zeigt tiffinfo an?

http://linux.about.com/library/cmd/blcmdl1_tiffinfo.htm


Bernd Mayer

[Wolfgang Weisselberg]

Was genau ist an so einer Bearbeitung "verlustlos"?

-Wolfgang

[Erich Brandt]

[Erich Brandt]

Ich antworte mir mal scheinbar selbst, weil ich zu faul bin, nach zu
schnellem Klicken die Originalantwort von Dir wiederherzustellen.

Darf ich ein Bildverarbeitungsverfahren, das Änderungen (nur) in
beigepackten Dateien hinterlegt - die Original-Bilddateien also nicht
direkt anfaßt oder (neu) abspeichert -, nicht als verlustlos bezeichnen?

Ciao, Erich

[Wolfgang Weisselberg]

Erich Brandt <erich....@googlemail.com> wrote:
> Am 29.04.2013 23:56, schrieb Erich Brandt:
>> Am 29.04.2013 15:58, schrieb Wolfgang Weisselberg:
>>> Erich Brandt <erich....@googlemail.com> wrote:
>>>> Am 17.04.2013 22:14, schrieb Wolfgang Weisselberg:
>>>>>>> ASP ist ein Kamera-Rohdaten-Bearbeitungs-Programm.

>>>>>> Nicht nur, es kann auch jpg und manche tif bearbeiten.

>>>>> Man kann mit einem Auto auch fliegen --- z.B. hinter einer
>>>>> Rampe oder eine Klippe runter ...

>>>> Was stört Dich daran, daß ein Rawdaten-Konverter neben diversen Raws
>>>> zusätzlich einige andere Dateiformate bearbeiten kann - ebenso
>>>> verlustlos wie die Raw-Dateien?

>>> Was genau ist an so einer Bearbeitung "verlustlos"?

> Ich antworte mir mal scheinbar selbst, weil ich zu faul bin, nach zu
> schnellem Klicken die Originalantwort von Dir wiederherzustellen.

> Darf ich ein Bildverarbeitungsverfahren, das Änderungen (nur) in
> beigepackten Dateien hinterlegt - die Original-Bilddateien also nicht
> direkt anfaßt oder (neu) abspeichert -, nicht als verlustlos bezeichnen?

Nein. Es ist reversibel. Die Verarbeitung selber vernichtet in
der Regel einen Teil der Daten. (Wenn du z.B. die Sättigung
veränderst, verschiebst du Pixel-RGB-Werte immer nicht 100%
reversibel. Bei 16bit Bearbeitung aus einer 8-bit-Quelle geht
es meist noch, aber spätestens, wenn du auf 8-bit ausgibst,
liegen vorher benachbarte Werte gerne teilweise direkt
aufeinander. Extrembeispiel: vollständig entsättigen.)

Wenn du eine Kopie der Original-Bilddateien verwendest und
diese Kopie mit Gimp bearbeitest, ist 'reversibel' auch gegeben.

Korrekt ist allerdings, daß du beim Gimp nicht unbedingt
in wahlfreier Reihenfolge die Operationen außer der Reihe
nachkorrigieren kannst, ohne die danach folgenden Operationen
wiederholen zu müssen --- da kann man zwar einiges mit Ebenen
machen, aber eben nicht alles. Und es ist halt Handarbeit.

Das könntest du allerdings auch haben, wenn du die Schritte
z.B. als Script für imagemagick schreibst: da kannst du auch
zurückgehen und einen Schritt verändern und das Bild ganz
neu rendern lassen, um zu sehen, ob das jetzt passt. Musst
nur das Script als Sidecar zum Original-Bild speichern und
bei Bedarf erneut ausführen. Das ust dann auch 'verlustlos'.
:-)

-Wolfgang