ok so the default raw decription of bayer array making visible colors RGB is that different as the X-trans sensor works and delivers its raw file, that the coreprogramming of DxO PL has to be rewritten in order to read the rawinfo?
something like that?
As i recall an other “small” users base like Silkypix does have Fuji support.
it has to be more then just rawfile support apperently
(i don’t want to bash and smash, but just understand this kind of decisions, because they have a fanbase out there so it is a open field to enter.)
I absolutely love PhotoLab but this Fuji business is perplexing and infuriating. I would like to move to Fuji as the image quality is superb but that would mean moving away from PL, which I do not want. Given the rough time DxO have had and with the push now on to make PL even better I would have thought support for Fuji would be high on the agenda. Is it really just a coding issue?
I am sure we all could survive photovit, but that is not the question really. Presumably you are no longer a DxO user for as you say - you can survive without it.
This message will be a little technical, but it gives more insight about why Xtrans are not supported. Apart from the need to rewrite demosaicing algorithm to adapt it to XTrans structure (which every competitor supporting XTrans had to do), main specificity of OpticsPro / PhotoLab is that it already does many processing BEFORE demosaicing, for example to get a more efficient denoising (demosaicing changes noise structure - making grain rougher - and makes it more difficult to remove after that). For instance, we would need to deeply adjust algorithms like PRIME (or also our more standard denoising). Thus keeping Photolab specificities in image quality on XTrans comes with a high cost of development, that we preferred until know to invest in features dealing with a larger base of customers.
Interesting, so the competition makes its denoising after demosaicing, making it harder for them to offer a DxO comparable denoising quality, but at the same time allowing them to exchange the demosaicing algorithm to adapt to different sensor architectures.
I guess the question is: is the quality of X Trans images so good that denoising becomes less important? Next up is will X Trans or similar slowly take a greater share of the market thus adversely impacting PL’s market share?
sounds solid to me.
Never tested it, dont’ own a Fuij, but if you use ARC to (linear)dng, demosiacing is then done , its a extended 16bit tiff file basicly, is the PL software further usable for the Fuij?
i mean optical correction and such?
Or are there non Fuij related things done?
i suppose not because of the deep intangled rewriting thats needed.
Interesting suggestion. For now, linearDNG are not supported in PhotoLab, but even if we accepted such files, all algorithms before demosaicing (like PRIME) would be discarded, and thus XTrans customers would still lose a significant part of Photolab benefit (and it would imply using AdobeDNG converter or LR/ACR in a first step, making the workflow more complicated). I don’t know if after all this time, such tradeoff would be well perceived by customers. But you’re right, corrections like optical corrections, clearview, etc. could be easily applied.
Count me in. No Fuji support no buy. I use Fuji and Sony and I want to use only one program. There are lots to choose, so it can’t be that difficult for DXO, or is there another reason?
It is a kind of funny thing here. At first I realized that DxO OpticsPro I have bought is quite useless with Fuji X RAW format. “Ok” i thought - I can use Fujifilm X RAW Studio, convert RAW files to TIFF and process them in DxO OpticsPro.
But well not to be - Fujifilm X RAW Studio is not capable to process RAW to TIFF, only to JPEG.
I feel like both companies - Fuji and DxO are pushing me toward Adobe products
Did you try a other converter like Silkypix (supports fuji) to test this tiff in functionality?
(if you like you can supply a rawfile and i run it through sp7pro as tiff.
(it has: [film simulation](file:///C:/Program%20Files/ISL/SILKYPIX%20Developer%20Studio%20Pro%207%20English(EU)/Manual/man0006.html#_Anchor4.6.3.7)
Upload this tiff to your folder so you can see if its working like you expected. supported camera’s
ok let me know if you want a test file changed from raw to tiff by silkypix. i give you a link to a folder to upload. i will run it through in default and in “default film simulation” export as 16bit tiff and upload this in the same folder so you can download those.
Thank you! I did quick test of RAW therapy (64bits Windows 10 version) - it did a promising job. The learning curve of RAW Therapee is not the best one but I want to get it a chance.
Ah i see, its “powered by Silkypix” so i think its the same algorithm as in the full Silkypix developer.
That is the native raw to pixel (demosiacing) of fuji. That wil give you the best startingpoint.
It is for some tools of DxO “not working on tiff” but you can test this by using a rawfile DxO can cope with and feed DxO a rawfile and a tiff file(produced by a rawconverter (not DxO because it is doing automated corrections which will embedded in that tiff.).
Turn everything on and start working on that raw file.(only the rawfile)
And after that copy paste to the tiff file. (check which settings are turned off in the tiff file version.
Then export both jpegs. See if there are differences.
This way you can detect which things you lose in DxO appart from primenoise running tiffs.
Forgot to write, you can use Dfine2 of NIKcollection to compensate the loss of Prime a bit.
export in dxo to dfine as 16bit tiff, import again as 16bit tiff and export to 8bit jpeg
