[Nikon d70] NEF is deze losless ?

[Wim.Vanmaele]

Voor de echte techneuten:

http://www.majid.info/mylos/weblog/2004/05/02-1.html

Op het eerste zicht, bij het hernoemen van de extentie nef naar tif, kan ik aan heel wat informatie geraken in het EXIFTIF gedeelte. Wanneer ik de extentie nef laat, kan ik ook aan data. Dus dit zit goed voor ontleding. Komt er nu op aan om na te gaan of ik ergens toch sporen weet te vinden van compressie ... Normaal staat dat ook ergens in de header ...
Mijn dagen worden tekort. Dringend een nieuwe firmware-update nodig van 24 uur naar 36.

[Kevlar]

Te technisch voor mij maar wel heel interessant. Ik vraag mij wel af of je wel zeker mag zijn dat canon geen compressie heeft op zijn raw files. Zou kunnen hoor ik weet het enkel niet.

[KoFFiE]

Originally posted by Kevlar
Te technisch voor mij ...

Net het omgekeerde probleem - had liever wat meer technische uitleg gehad, bvb welk quantization algorithm ze gebruiken (indien dit bekend is natuurlijk - en vermits dit in de firmware van Nikon zit is dit niet zo obvious om te achterhalen). De curves die ze gebruiken zijn er blijkbaar wel - maar het is niet duidelijk of deze dynamisch zijn (afhankelijk van belichting etc) - of static - wat al een groot verschil zou kunnen maken.

Wat ik eigenlijk niet goed snap is dat men hierop zit te kappen - vermits het hier om een compressie van 12bit per kleurkanaal naar 9.4bit/kleurkanaal gaat. Feit is dat geen enkele grafische kaart of scherm op PC momenteel meer dan 8bit per kleurkanaal kan weergeven, de 32bit kleuren bestaat namelijk 4 8-bit kanalen, Rood, Groen, Blauw - en een Alpha-transparency-channel, waarvan het laatste door je grafische kaart wordt ingeblend, en dus eigenlijk van geen enkel nut is bij de uiteindelijke weergave. Bij het tonen van de foto's op je scherm is deze waarde toch altijd dezelfde - namelijk 255, want je foto's zijn niet echt transparant
De kleurdiepte die je camera dus vastlegt zal je dus nooit op je scherm te zien krijgen - of dit nu 12 of 9,4 bits per kleuren is, je verliest meer detail omdat je de foto aan het bewerken bent op een lager kleurdetail dan het feitelijk is dan door deze lossy compression, gewoon omdat je niet alle details kan zien op je scherm. Je blijft natuurlijk met het probleem zitten dat je kleuren licht vervormd zijn door de oneven transformatiecurves (als ik die in het artikel bekijk toch)

Dat je aan de EXIFTIF data kan is waarschijnlijk omdat Nikon een variante op het TIF formaat heeft gemaakt met een hoop custom tags (wat vrij simpel is bij TIF).

[MarcFoto]

kZal nog maar een paar fotokes gaan maken, want ik versta hier (weeral) de ballen van...
Tenzij jullie de tijd zouden willen nemen om het mij uit te leggen natuurlijk...

[KoFFiE]

Originally posted by MarcFoto
kZal nog maar een paar fotokes gaan maken, want ik versta hier (weeral) de ballen van...
Tenzij jullie de tijd zouden willen nemen om het mij uit te leggen natuurlijk...

De hele technische achtergrond ga ik u van besparen Komt erop neer dat je de compressie van Nikon idd niet lossless is - minder kleurdetail, maar dat je de schade die zij daarmee doen toch zowieso in de nabewerking op PC berokkend wordt, een PC kan zo'n kleur-resolutie namelijk gewoon niet weergeven - en als je dan gaat bewerken terwijl je een heel deel van de details gewoon niet kan zien.

De persoon die gaat beweren dat hij kan zien of er dit type compressie is toegepast of niet lach ik gewoon vierkant uit. Als je over zo'n kleurdetails gaat praten dan gaat je type en kwaliteit van sensor, algemene instellingen van je camera en belichting van veeeeeeel groter belang zijn dan het kleurverschil dat je ooit gaat krijgen door deze compressie.

Ik vermoed dat als die compressiecurves dynamisch zijn aan de belichtings-situatie dat het zelfs nog sterker is, namelijk dat zij de fout die daarbij gemaakt zal worden zullen verminderen, hoewel ik daar niets van bewijzen voor heb om dit te staven. Uiteindelijk zal dit verschil toch nooit zichtbaar zijn voor het menselijke oog.

[j@n]

Originally posted by Kevlar
Te technisch voor mij maar wel heel interessant. Ik vraag mij wel af of je wel zeker mag zijn dat canon geen compressie heeft op zijn raw files. Zou kunnen hoor ik weet het enkel niet.

Canon past bij de 1D Mark II een verliesvrije zip-compressie toe. Daardoor is de grootte van de 16 bits RAW met 8/9 Mb nog acceptabel. Uitgepakt wordt dat 48.6 Mb.

[Kevlar]

Originally posted by j@n

Originally posted by Kevlar
Te technisch voor mij maar wel heel interessant. Ik vraag mij wel af of je wel zeker mag zijn dat canon geen compressie heeft op zijn raw files. Zou kunnen hoor ik weet het enkel niet.

Canon past bij de 1D Mark II een verliesvrije zip-compressie toe. Daardoor is de grootte van de 16 bits RAW met 8/9 Mb nog acceptabel. Uitgepakt wordt dat 48.6 Mb.

Ja compressie moet natuurlijk niet met verlies zijn ook niet had ik effe niet aan gedacht toen ik dat artikel las. Ik vroeg mij enkel eigenlijk af of er iemand dat ooit bij canon gecontrroleerd had.

Maar alvast bedankt voor de info.

[Laurens]

Originally posted by KoFFiE
[br
.... Feit is dat geen enkele grafische kaart of scherm op PC momenteel meer dan 8bit per kleurkanaal kan weergeven, de 32bit kleuren bestaat namelijk 4 8-bit kanalen, Rood, Groen, Blauw - en een Alpha-transparency-channel, waarvan het laatste door je grafische kaart wordt ingeblend, en dus eigenlijk van geen enkel nut is bij de uiteindelijke weergave.

Matrox heeft kaarten die meer dan 8 bits/kanaal gebruiken. De Parhelia kan 10 bit per kanaal aan. Dat moet je best wel een CRT combineren want TFT-schermen hebben zelf ook nog eens een bepaalde bitdiepte. Ik dacht dat enkel Eizo al over de 8-bit grens raakt met hun topmodellen maar helemaal zeker ben ik daar niet van.

[KoFFiE]

Originally posted by Laurens

Originally posted by KoFFiE
[br
.... Feit is dat geen enkele grafische kaart of scherm op PC momenteel meer dan 8bit per kleurkanaal kan weergeven, de 32bit kleuren bestaat namelijk 4 8-bit kanalen, Rood, Groen, Blauw - en een Alpha-transparency-channel, waarvan het laatste door je grafische kaart wordt ingeblend, en dus eigenlijk van geen enkel nut is bij de uiteindelijke weergave.

Matrox heeft kaarten die meer dan 8 bits/kanaal gebruiken. De Parhelia kan 10 bit per kanaal aan. Dat moet je best wel een CRT combineren want TFT-schermen hebben zelf ook nog eens een bepaalde bitdiepte. Ik dacht dat enkel Eizo al over de 8-bit grens raakt met hun topmodellen maar helemaal zeker ben ik daar niet van.

Een CRT kan dit perfect aan omdat deze analoog wordt aangestuurd, en de Parhelia kan idd 10bit/kanaal aan, maar hoeveel volk heeft die (zeer moeilijk te vinden) kaart? De laatste grafische kaarten van nVidia en ATI kunnen trouwens zelfs 16bit/kanaal aan - wat in totaal 64bit colors oplevert en kunnen zelfs floating-point kleuren aan - wat nog meer nauwkeurige kleuren zou moeten opleveren, maar beide kleurresoluties zijn d8 ik enkel bedoeld en beschikbaar in 3D acellerated modes, en weet niet hoe dit in normale 2D-accelerated mode zit...

[Wim.Vanmaele]

@Koffie

Wij moet dringend, dringend eens praten. We wonen op dezelfde gemeente, hebben dezelfde virale infecties.

http://forum.belgiumdigital.com/topic.asp?TOPIC_ID=51097

Hier hangt iets zinvols in de lucht. Heb ook al een hersteltool ontwikkeld voor JPeg-bestanden (te vinden in home-page BelgiumDigital, download).
Inderdaad, ik weet immers welke tags Nikon toevoegt aan de header.
Er is immers een segment beschikbaar voor Makerpictures. Deze wordt door iedere fabrikant naar eigen 'goesting' ingevuld. Ik heb daar reeds verschillende mappings voor

http://preserve.harvard.edu/resources/imagemetadata.pdf

[KoFFiE]

Originally posted by wimvan
...

Hehe wil da gerust wel is doen. Grote prob dat ik nu heb is dat ik zeer weinig tijd heb (druk op't werk en sociale verplichtingen enzo). Ge kunt mij ondertussen wel altijd vinde op het #belgiumdigital kanaaltje op kreynet - waar ik 24/7 idle Tuurlijk is is een pint gaan pakke ofzo wel wa aangenamer

Heb even naar het topic gekeken, en zie dat je in Pascal (ieuw - brings back bad memories ) ontwikkelt in't algemeen... Geef mij maar een C-alike taal...
Ik denk dat ik ooit (lang geleden) al een hoop code geschreven heb die je wel zou kunnen interesseren (o.a. lezen, decoden en encoden van TIFF, GIF en Bitmap images - en het prille begin van een JPG decoder) en mocht die schijf waar dat opstond niet enkele jaren geleden zwaar gecrashed zijn zou ik je die met plezier bezorgen... ( I know - backups hebben hun nut af en toe - maarjah - te laat... )