Stacking 10 images in P'shop to raise rez

[bruce1951]

Hoogo I should have stated 'every thing else being equal'. 8bit? 16bit? 32bit? etc etc etc. That's why my 30 meg NEF's end up at 140meg. Nothing ever is 'equal'!! Does a 6000x4000 image that is solid white have the same amount of data as a 6000x4000 landscape?

regards

[cathodeRay]

Ken/Hoogo - I'm not sure the 100/158% magnification thing matters - it's just the standard technique for comparing 'like for like', at least in dimensions. You could leave both at 100% or leave the standard image at 100% and downscale the bigger image, and a wow difference would still be visible. Since really the main point of doing these very high resolution/huge pixel count images is to provide latitude for either mega-enlargement and/or zoom & crop that would pain conventional images, despite my earlier caveats about the tower not mattering in the bigger picture, it is still valid to pixel peep (if so doing tickles your fancy) to see what detail is there.

In all this I am reminded of a principle sometimes heard in (medical) research: better an approximate answer to the right question than an exact answer to the wrong question. It's all too easy to be seduced into investigating X because you can do/measure X when in fact it was really Y that matters most.

cR

[bruce1951]

Ken I've had a nights sleep and now my brain has rearranged some particles!
6000x4000 is NOT always the same size and can contain the different amounts of data. What was I thinking. So 'us experts' are on the wrong track!!!!

So adding extra layers and therefore data does alter the amount of data even though the 6000x4000 remains the same. (Actually trimmed in the process of stacking).
eg. I almost always shoot 3 brackets. D7100. NEFs. On a 'typical' image I have the following files sizes. 0ev is 28.5meg. -2ev is 28.78meg and the +2ev is 31.5meg. So if they are all 6000x4000 they can't all be the same!
Combine those three files for a HDR/Tonemapped image I get 140.1meg. Still at 6000x4000.

My point being. That, like HDR brackets, Stacking will also add data and therefore make the file larger.

Time is tight today so I haven't the time to find some of my stacks to 'prove' my point.

regards

[bkh]

On a 'typical' image I have the following files sizes. 0ev is 28.5meg. -2ev is 28.78meg and the +2ev is 31.5meg. So if they are all 6000x4000 they can't all be the same!
Combine those three files for a HDR/Tonemapped image I get 140.1meg. Still at 6000x4000.

Really depends on what you mean by "data" (or information content). Does a 6000x4000 which is pure white contain less information than an ordinary photograph? What about an image just consisting of noise? From another point of view, an image with shallow depth of field contains less information about the background, but it contains more depth information than a photograph with sharp background.

Btw., file sizes aren't a reliable measure of information content. Creating a TIFF file from a 6000x4000 NEF file adds interpolated pixels and a few unused bits per pixel, so it's usually around 140 MB. Does it contain additional information? (I'm inclined to say: no.) Shoot the same image at ISO 100 and ISO 3200. The NEF file at ISO 3200 will be larger (because of the additional noise – does that mean more information?) Also, a lzw compressed TIFF file is usually much smaller than an uncompressed TIFF, yet both contain the same information (especially for 8 bit tiffs).

Cheers

Burkhard.

[bruce1951]

Burkhard I guess it all comes down to definition. The big danger in making any clear cut statement is that someone is sure to come along with a counter statement that contradicts your own statement! Theory and practice?
Either way an image with any sort of detail in it should always be 'lager' than an image of white wall. The key word here is 'should'. So keep adding detail, layers/stacks, and the amount of date 'should' increase.

regards

[photoken]

Ken I've had a nights sleep and now my brain has rearranged some particles!
6000x4000 is NOT always the same size and can contain the different amounts of data. What was I thinking. So 'us experts' are on the wrong track!!!!

So adding extra layers and therefore data does alter the amount of data even though the 6000x4000 remains the same. (Actually trimmed in the process of stacking).

Sorry, Bruce, but I was never talking about the pixel dimensions. I was always talking in terms of the content of the pixels. So, I stand by my previous statements -- if you start with a stack of images that have "x" number of pixels, those pixels all have some kind of data. When you do focus stacking, you're taking some data from each image and discarding some data from each image; you end up with a single image that has no more data than any of the original images.

Burkhard is right about this being a matter of semantics: what does "data" mean? My point is that any given pixel has data -- a series of numbers describing the RGB values of the pixel. When you look at the entire image, those points of data might be useless (noise), or those points of data might be irrelevant (a pure white image), or those points of data might be unwanted (blurred objects), or those points of data might be desired (sharply defined objects).

I like Burkhard's distinction between "data" and "information" -- every pixel in every image contains "data", but it's up to the user/viewer to decide whether that data is the "information" that is wanted.

[greenmorpher]

OK another 'slant'.
…
Hmmmmmm. Come on. I want a DSLR that will do focus bracketing.

bruce

If you could settle for m43, it is present and doing its stuff, Bruce.

Ken mentioned Panasonic's 4K implementation. As I understand it, Olympus does automated focus stacking better with the full 16/20MPX available.

Cheers, Geoff

[greenmorpher]

Ken, Bruce, and Burkhard

Wouldn't you get a smaller file size for an HDR of a pure white surface than for an HDR of a pebbled, multi-color surface?

You would in JPEG, of course, because that's what it does, but in other formats, surely there must be some economies available in the way the next pixel is recorded if it is the same?

Hence an HDR with more detail revealed necessarily is a bigger file than a file with less detail.

Or am I off with the fairies here?

Cheers, Geoff

[greenmorpher]

I asked the original poster on DPReview for more information about his "stack" that produced many more pixels, but he hasn't responded. He is now off on a rant charging that m43 sensors haven't shown any development in five years so he is going to have to move to another format. I don't think we will get any elucidation about his stack.

Cheers, Geoff

[bruce1951]

Greenmorpher I like being in 'control'. So I'm not interested in in camera functions as such. (Ideally I want a camera that can function like programs such as ControlMyNikon).

As for the 'technicalities/terminology' of larger/smaller files etc I'm getting out of my comfort zone. I know what I know from watching my files grow or shrink. The how or why is where we all have various opinions. Others on this forum have experience/knowledge in areas that I don't. So I'm leaving well alone before I get a brick through my window. But in 'my' experience HDR and stacking almost always results in large files. It may well be the way I edit/construct these files. (For interest I HDRed blank white, black and grey files. After it crashed Photomatix twice I got a red file that was approx 20% smaller in megs than the original files. All the files started as 183meg. The final tonemapped file was 137meg. So there you go. I got a smaller file!).

The problem is in definitions, opinions and experience. Forums are a hot bed of miss understanding and reading between lines. (I get into terrible trouble on another forum when I mistakenly use DPI instead of PPI. Or is it the other way around. One contributor 'stalks' me waiting for me to slip up. ).

regards

[cathodeRay]

Bruce, Ken and anyone else interested - putting aside any form of compression which obviously changes file size, my understanding is that an uncompressed single layer fixed bit size (say 16 bit) RGB tiff or comparable format should, metadata apart, always be the same file size, and always hold the same amount of data (made up of ones and zeros). This is because the format (at least in concept) allocates a grid of say 4000 x 6000 bins, and each bin holds the data for that pixel. It doesn't care whether the data represents white or black or anything in between, whether the data are so arranged that viewed en masse they are in focus or not, or whether they have a high or low dynamic range, or are great art or just noise. At a data level, the data is just neutral - in doesn't care what it means. It is then us humans (or perhaps machines programmed by us to see like us) that read information from patterns in the data.

If you add layers (stacking) of course the file size goes up, but once you flatten the image back to one layer, you should end up with the same intrinsic file size. Each bin has the same size, and hold the same data, which might be all zeros or all ones or anything in between - it doesn't care, the space is there, whatever goes into it. The flattening will (almost always) change the ones and zeros, but it's still the same number of ones and zeros.

The implication of this, for me is that if you have an uncompressed 4000x6000 RGB 16 bit image, you have a fixed amount of data (total number of ones and zeros), a fixed intrinsic file size, but what you can change, slightly or radically, is the information in that data. At a fundamental level, that is what PL does: changes the data so we see different information, a different image.

DPI, PPI and LPI soup - I mentioned them earlier - best not to go there, methinks!

Geoff - folk being coy about their methods always makes me wary. It's like scientists who release only their conclusions, but not how they got there. Take them with a large, very large, pinch of salt.

cR

[photoken]

Ray,
I like your explanation of what I was trying to say.

At a data level, the data is just neutral - in doesn't care what it means. It is then us humans (or perhaps machines programmed by us to see like us) that read information from patterns in the data.

I couldn't agree more!

[greenmorpher]

A couple of mentions have been made in this thread of pixel shift technology.

Avery interesting thread on this has just appeared in the DPReview m43 forum.

https://www.dpreview.com/forums/post/58983787 is the OP comparing output from a Canon FF and Olympus EM5 II with pixel shift.

https://www.dpreview.com/forums/post/58983918 is the OP outlining his processing.

https://www.dpreview.com/forums/post/58984009 is a subsequent post from the OP comparing output from a Pentax 645 nd Olympus Pen F (the digital version!) using pixel shift.

Note that absolutely no claims are made for the universal application of this technology! The OP is very careful in this respect. <i>Of course</i> it won't work with moving subjects (which rules it out for me documenting earthquakes here in paradise where the earth moves for everyone! But wait, maybe it could work, we just measure the difference between the two images… No, let’s not get into that. LOL.).

Cheers, Geoff

[bruce1951]

cathodRay I understand the mathematics and theory. (Many years ago I studied computing etc etc). That's not the issue. I 'think' what I'm simply trying to point out is that there are too many 'other' factors at play to give anyone a simple black and white answer.
As Ken pointed out a 6000x4000 image 'should' be a straight forward calculation. I agree with Kens comments. But it never is as simple as it seems due to 'other' factors. All my NEF's are 14bit giving a 6000x4000 image. But no two ever have the same file size/megs. A simple explanation doesn't answer the question of 'why aren't they the same?' Likewise. HDR/Stacking results in varying file increase or decrease due to the 'other' factors.

Me thinks we have gotten away from greenmorpher original post for which I'm sorry.

regards

[cathodeRay]

Bruce - I recall Geoff may have earlier described the discussion as fascinating, so we may have got away with it (this time!). The post above wasn't an attempt to teach the many experts here how to suck eggs, but more in the spirit of a public note to self.

Apart from real file size changes caused by stuff outside the image itself (metadata etc) and/or compression, maybe the question that really matters when file size changes whether the change, especially if it is to a smaller file size, has in some way degraded the image. To assess that we have various blend modes that can throw light (sic) on the matter, not to mention graphs and plots, but probably what matters most is what the Mk 1 eyeball tells us, though of course that Mk 1, wonderful as it is, is also capable of getting tired and/or confused. But since (at least for now) it is we humans who enjoy or don't enjoy a particular image, the Mk 1 is still probably the ultimate acid test. If the numbers are weird, so be it (though, perhaps like you, I have a tendency to always want to try to understand); as long as the image looks good (enough), then it is good (enough). Good (enough), by the way, is the tipping point I use to decide when to stop working on an image - otherwise I would be at risk of working on the same image for ever!

cR