Hig res in studio scenes

Started 5 months ago | Discussions thread
evan ts Forum Member • Posts: 64
Re: Hig res in studio scenes

knickerhawk wrote:

evan ts wrote:

knickerhawk wrote:

evan ts wrote:

knickerhawk wrote:

evan ts wrote:

There are many algorithms that can combine many low-res images into a single hi-res image.
(This one was announced 15 yeas ago: https://users.soe.ucsc.edu/~milanfar/publications/journal/SR-challengesIJIST.pdf )

I think that Silkypix just uses a newer and better hi-res algorithm than ACR.

But that's not what's going on at the raw converter stage to a HiRes raw file. The camera internally merges the subframes using a fixed algorithm (perhaps similar to what's discussed in the linked paper) and outputs an ordinary looking Bayer-style raw file, albeit a much larger one constructed from the subsampling of each normal-sized pixel position. The raw converters are not called upon to do anything different with one of these HiRes raws than they do with normal raws.

The hi-res takes 8 Bayer-shots (2 RGB-shots). The key point is, pixel size is still the same as a normal shot. When all shots are stacked together, pixels are overlapped. So we need a good algorithm to separate the information of overlapped pixels.

Yes, that's understood and implicit in my reference to "subsampling of each normal-sized pixel position." What you're not addressing is my point that the "good algorithm" you're referencing is applied in camera during the construction of the Bayer-style raw file, not later in the raw converter. Consider this: When the S1R generates a HiRes image does it output 8 individual/interim raw image files or just one? If it's the former, then you would be correct that the raw converter would have to have a built-in capability of handling the 8 samples per subpixel position. But in fact it's the latter, which means that the camera has already done the heavy algorithmic lifting for merging the subsamples into a specific R,G1,G2 or B value for each of the subpixels. This allows the raw converter of choice to simply see the raw file as a normal Bayer style RGGB raw file.

I think the hi-res raw file just contains 8 copies of RGGB values. (and embedded thumb jpeg)

In which case the HiRes raw file would be approximately 8x the size of a normal S1R image, but it isn't. For instance, the DPR studio scene normal ISO 100 S1R raw image is 67 MB. 67x8=536 MB, which is what we would expect if the 8 sets of RGGB values are maintained in the raw container file. However, the actual size of the DPR ISO 100 SIR HiRes raw files is 337 MB. None of the mFT Panny or Oly HiRes files work the way you're thinking. They work the way I've explained.

8 RGGB shots can be stacked into 2 RGB shots. The size is reduced to 6 times of a normal raw. Store it in a size-efficient format and minus the space of embedded JPEGs. I think the 5-6 times of size is reasonable.

If you were right, hi-res has 4x pixels, RGB 3 colors in each pixel. The size should be 12 times.

 evan ts's gear list:evan ts's gear list
Canon EOS M Fujifilm X70 Olympus PEN E-P5 Panasonic Lumix DMC-GM1 Panasonic Lumix DMC-GX85 +8 more
Post (hide subjects) Posted by
Keyboard shortcuts:
FForum PPrevious NNext WNext unread UUpvote SSubscribe RReply QQuote BBookmark MMy threads
Color scheme? Blue / Yellow