All True!
Irfanview is good for batch correcting (resizing!) the INCORRECTLY sized TIFFs DxO makes from RAW files… sometimes.
Infanview is not an Image Browser.
So why has it got/you given it a capital V?
iView is a completely different piece of software.
Anyway, it has nothing what-so-ever to do with the issue with DxO PLab Jason reported, and I have also come across.
1 Like
Thank you, Mike. I was wondering why this discussion was moving from “hey, PL is going something wrong” to “get this other tool to get that”. Shouldn’t PL be preserving the images size if I don’t modify it? And you are also correct, there’s no compression here. PL is just writing the wrong images size – not the same as the RAW source image.
By the way, I should mention that this is happening only with my darks – photos taken in complete darkness to tease out the hot pixels which are then subtracted from the light photos. Whether I have a lens on with the lens cap or just the body cap, completely dark photos are always exported to a different size, always larger. I just exported another series of darks and they were 4620x3456, twelve pixels wider that the RAW.
It’d be great if someone from DxO would chime in.
I just tried with lens cap. No difference with me. Saving both tiff and jpg. Did you try to save as jpg?
George
i noticed a few years back that a Rawfile in dxOpl showed a different angle of view then Silkypix v7pro.
main reason was the optical module. The DxOPL was bigger/wider.
The “distorion correction crop” as default (not the one you do in perspective) can be differ from rawdevelopers applications.
And it maybe counts those who layes outside the quadrant before export which then be cut off.
hence the lower numbers.
Could be dono, sounds resoanalbe.
A comparison that I made several years ago. (which explains why DxO and not PL in the picture).
- Below, what is recorded by the sensor = PL without distortion correction)
- Top left, PL with lens module distortion correction.
- On the top right, the corrections in ACR (LR, PS) made automatically with the manufacturer’s correction data embedded in the raw (m4 / 3 standard). The jpeg out of the box is absolutely identical.
PL gives more!
1 Like
I’m wondering if a solution to this has been found. I’m experiencing the same thing on a Mac with my stacking program Zerene Stacker and for some reason some of the files are like one or two pixels off of the original, which makes it impossible for the program to stack. My workaround has been to batch-resize all of the files in Preview, but I’m honestly wondering why PhotoLab 8 started doing this. I batch processed images for stacks before using PhotoLab 8 and they worked fine when stacking, but for some reason the files are one or two pixels bigger or smaller than the original RAW file dimensions. The only part of my workflow I changed that coincided with this weird behavior from PhotoLab is utilizing an older lens I had (so I had to download the module for the respective lens). Interestingly enough, after ignoring PhotoLab 8 and running the images through PureRAW 4, Zerene Stacker worked fine and stacked the images perfectly, so this has me believing it is the fault of one of the settings or adjustments in PhotoLab 8 and not necessarily my camera or lens.
Don’t use lens corrections. Don’t use any preset.
George
Thanks for the input, I’ll try this out. I’m confused is all because it was working fine with lens corrections on my other lens. Oh well.
Distortion correction changes the size, or can change the size. It also depends on the used focal length if you use a zoom lens.
George
1 Like