- This topic has 6 replies, 4 voices, and was last updated 9 years, 4 months ago by
.
-
Posts
-
Op zich een inkopper, 32- danwel 64-bit natuurlijk. Maar ik wil die mooie foto afdrukken en de drukker geeft alleen een mogelijkheid tot 16-bit jpeg. Prima, dan bewaren we het resultaat als 16-bit jpeg, jpeg vervolgens beetje tweaken en drukken maar. Dit is wat ik nu gedaan heb, de jpeg ziet er prima uit, maar ik vraag mij af of het niet beter was geweest om vanaf het begin in 16-bit te werken. Nu gooi je daarmee data weg, maar als een jpeg toch het doel is, kan je dit weggooien dan niet het beste in het begin laten doen door PI?
Ik persoonlijk zou de “stretch” schaal van minimaal 32 bits gebruiken om details naar voren te halen, en aan het eind pas de compressie “zijn werk” laten doen. Dit lijkt mij beter dan andersom?
@supernov, ik denk dat je dit sowieso los moet zien van pixinsight… en het is een hele fundamentele vraag voor onze astro foto post-processing.
@mth75 zijn gedachte is de spijker op zijn kop ;-), je wilt de compressie naar 16bit zo lang mogelijk uitstellen. Ik maak de data pas 16bit in de laatste stretch naar een TIFF of 8bit naar een JPG voor presentatie. Dus dan gebeurt de stretch vanuit de lineaire data in 32bits en je slaat het resultaat op als een 16bits TIFF of een 8bits JPG bijvoorbeeld.Dit is 1 van de redenen waarom het processen van astrofoto’s in Photoshop natuurlijk niet ideaal is, omdat niet alle bewerkingen in 32bits gedaan kunnen worden in PS. Maar wat je allemaal verder kan in PS, maakt natuurlijk veel goed ;-)
64bits? als iemand een voorbeeld heeft dat je moet stretchen in 64bits om verschil te zien dan zie ik dat graag. Ik heb onlangs nog aan meerdere fotografen gevraagd of ik in APP een 64bits stretch moet inbouwen. Niemand vond dat nodig. (Maar als het toch nodig is, kan ik het zo inbouwen gelukkig)
Ok, maar waarom precies wil je dat uitstellen, ik wil zo’n enorm lang antwoord Mabula dat snap je toch zeker wel. ;) Op gevoel zou je kunnen denken dat het kalibreren en stacken in 32-bit kan om vervolgens het tussen-resultaat al in 16-bit te zetten, het idee is dan dat PI hier optimaal mee omgaat. Als ik het zelf gewoon hard omzet naar JPEG met alle waarschuwingen van PI, dan vraag ik mij af of ik juist dan niet meer data weggooi.
ps: In het geval van HDR data is dit overigens eenvoudiger voor te stellen, dat wil je idd niet tussentijds naar 16-bit zetten omdat er nog compressie nodig is in de niet lineaire fase.
@supernov, hoe meer bewerkingen je nog doet terwijl de data al 16bits is , hoe groter het risico dat er posterisatie optreedt ergens in je foto.
Als je slechts kleine subtiele bewerkingen doet in 16bit zul je er vrijwel nooit wat van zien, is mijn ervaring. Maar als je nog flink gaat rekken en veel speelt met contrast en saturatie bijvoorbeeld, dan is de kans groot dat het optreed. Dit kan soms subtiel zijn, dat je het zelf niet echt ziet. Maar als je dezelfde bewerkingen had gedaan in 32bits, en dat er naast zet, dan zou je het wel goed zien.
Dus soms ben je er niet van bewust en haal je een minder resultaat dan mogelijk was.
Calibratie van 16bits data doen in 32bits data is denk ik niet veel waard. De meetonzekerheid in de 16bits (of 14bits bij je dslr) opname die gecalibreerd wordt is groter dan de enkele ADU waarde in de 16bits range. Dus de data in 32bits zetten voor calibratie is denk ik iets waar je niks mee wint. Althans ik denk het niet. Misschien bespreken in de beta groep?
Voor stacken moet de data zeker wel 32bits zijn, dan kan de diepte van de data uitgebreid worden. Hoe meer subs je stackt, hoe meer bitdiepte er in je data komt ;-)
Ah ja, de stappen kunnen minder subtiel zijn als je data-range simpelweg kleiner is, dat klinkt heel logisch. Ik zat echt meer te denken aan de processen in PI welke hier dan wellicht alsnog beter mee om konden gaan, dan hetzelfde tweaken in het eind-stadium van 16-bit. Maar als er geen data voorhanden is, dan zal geen enkel algoritme hier wat mee kunnen. Thanks!
- You must be logged in to reply to this topic.