I’ve finally begun to learn in earnest photo stacking for astrophotography. The stacking software I use is quite picky about the input images and complains when all inputs are not exactly the same dimensions. I started checking on this and sure enough, my RAW photos are all 4608x3456. But, many of the TIFs in my exports from PhotoLab are 4610x3456.
Note: I am using version 1.2.3 build 82. Yes, I realize it’s old, but even so it should not be doing this. I’ve never noticed before because it was never so critical to my workflow before.
Here are my export settings. And suggestions beyond having to manually edit dozens of images by hand?
Raw shows the pixel count of the sensors. Due to the conversion of the bayern array a row and a column is disappearing on each side. I’m more surprised why it didn’t change to 3454.
An image is always different in size from the sensor. Be aware when viewing a raw in an image browser the embedded jpg is shown. I’m not sure which figures are used: from the raw or the jpg.
You can also compare the out of camera jpg with your sensor dimensions.
Sorry, I don’t quite understand your suggestion. I am selecting and exporting i PhotoLab – which is why I’m posting about it here What gives the indication that I am compressing the photos before stacking? Do you mean when I convert to TIF I am compressing them? If I have something in my DxO export parameters to compress, it is because I am unaware of it. Can you show me how you came to that conclusion? If it is simply a basic effect of exporting, until recently the stacker I use could not take RAW files and I had to convert them to TIF first. I chose TIF, as opposed to JPG, because I was under the impression that 16-bit TIF would be exported without compression. If you can see from what I have offered in my original post that I am using compression, please explain.
My mistake. I meant resizing. And even that is wrong. In your interface the resizing properties are shown but the button “enable resizing” is not activated. In pl3 the resizing properties are only shown when that button is activated.
I found the same trying to stack Comet Neowise images recently in Deep Sky Stacker.
I was baffled by this ‘unusual’ DxO behaviour. I’ve got an old version of Photoshop that allowed me to use Adobe Raw Converter and it didn’t ‘resize’ my RAW > TIFF conversions.
I made an action in Photoshop to resize the 15 or so TIFFs before stacking them, but John-M’s idea of Irfanview is probably quicker.
From what I remember the problem came up with the light frames being (minutely) smaller than the Master dark frame and the software throwing up a warning.
Irfanview and all the other image browsers use the embedded jpg in the raw file. I know from Nikon that’s a full size file of middle quality, but still good. When saving that file that jpg is used. If that’s the way start shooting in tiff or high quality jpg.
Good suggestions, though it forces me to go through what really is an unnecessary step. It would be better if PhotoLab didn’t alter the dimensions or at least let me force them into to consistent dimensions when exporting.
Irfanview isn’t just any old viewer, it’s one of the most powerful and user friendly apps/programs for bulk changes or conversion of image file ‘details’. If you want to change the pixel dimensions to any size you want, it will do a folder of 200 in about 1 minute. Need a folder of 100 full size TIFFs to change to HD size mid quality JPEGs?, just define long axis dimensions… so portrait/landscape doesn’t matter. Need to change RGB to CMYK or 16Bit Grayscale?, easy.
Just WHY DxO does this remains a mystery?
I never mentioned iView to be an old viewer. I use it every day. It’s doing what I expect it to do.
But the image it shows is the embedded jpg in the raw file. When you save that file as a tiff it has only to pack the data in a right way. and write it to disk.
DPL is a raw converter. It has to create the rgb image first and probably does some editing on it depending on your preferences. And then it can be saved as some diskfile: tiff,jpg or dng.
If you don’t need a raw file but still want a high quality tiff image shoot directly in tiff. I think most cameras can do.
But an image browser is not the way to gain quality.
i’m not using irfanview to see anything, let alone mess with an embeded JPEG.
Agreed that why we’re using DxO PLab to convert RAW images, but on some occasions it produces a TIFF with different pixel dimensions to the original RAW. Something Abode Camera Raw doesn’t do with the same RAW file.
Funny, I never mentioned IView either.
Infanview is simply a good batch processor to CORRECT this occasional flaw in DxO PLab.
We have to be a bit careful with names. iView was an outstanding DAM software, got bought by Microsoft, changed name to Expression Media, got then bought by Phase One, changed name to Media Pro and got ultimately dumped and stopped by Phase One. Irfanview is something completely different and has nothing to do with iView.
I use both irfanview and iview and I’m not the only one. https://en.wikipedia.org/wiki/IView.
Back to the subject.
1)
I did make a selection in i(rfan)view of all my tif files from the D750. Looking in the image browser the sizes of the image are written in the buttom left. All of them where 4016x6016.If somebody does get different sizes then he must investigate why that is as it is. An interesting question would be, does it happen in jpg too.
2)
I just can’t see why any imagebrowser can help a rawconverter to write ‘right tif files’. The raw converter has to export them first, but in what? Tif, jpg,dng?
What gives the indication that I am compressing the photos before stacking? Do you mean when I convert to TIF I am compressing them? If I have something in my DxO export parameters to compress, it is because I am unaware of it. Can you show me how you came to that conclusion? If it is simply a basic effect of exporting, until recently the stacker I use could not take RAW files and I had to convert them to TIF first. I chose TIF, as opposed to JPG, because I was under the impression that 16-bit TIF would be exported without compression. If you can see from what I have offered in my original post that I am using compression, please explain.