Ah right, sorry, I see what you're saying. I've just had a deep dive and yes, the raw readers handling of Demosaic=none is broken.
When skipping the demosaic, the raw_image buffer we read from can actually contain "extra" pixels that are usually trimmed off. Additionally there won't be any rotation applied (which I only caught because my test image was rotated!). I was previously assuming the buffer was good to go, but it seems that isn't true. I'm fixing the behaviour now, along with my other patches, and I'll update here when I have a PR. Cheers, Mark On Wed, Jul 28, 2021 at 6:13 PM Larry Gritz <l...@larrygritz.com> wrote: > But if you are looking at the non-debayered image, it should be gray > scale, and also kind of weird looking because you're alternating some > pattern of R, G, B from pixel to pixel. This may be useless unless you know > what the pattern is for that camera and have your own debayering algorithm > to apply to turn the data set into a color image. > > But you OUGHT to be able to make visual sense of the image, nonetheless. > It will be odd looking, but should be recognizable as that scene. > > oiiotool --iconfig raw:Demosaic none > ../oiio-images/raw/RAW_CANON_EOS_7D.CR2 -o out.tif > > That does not yield an image that I would expect, even for a non-debayered > picture. > > Is the data layout of pixels different? When you ask libraw for > raw:Demosaic = none, does it in fact give you > > R(0,0) G(1,0) R(2,0) G(3,0) > G(0,1) B(1,1) G(2,1) B(3,1) > ... > > or are the pixels mixed up in some other way? > > Put another way: Is the OIIO code in the raw reader somehow mishandling > the request or what it does with the results, when you happen to ask for > Demosaic=none? > > > > On Jul 28, 2021, at 3:37 AM, Mark Boorer <markbo...@gmail.com> wrote: > > An alternate description might be this: > > In a regular image, you have an RGB triplet for every pixel. In a RAW > image, you have only *one* of R, G, or B for each pixel. The demosaicing > step is really just a fancy way to fill in the missing channels by > averaging from the surrounding pixels. > > So in your example 6x4 image: > > RGRGRG > GBGBGB > RGRGRG > GBGBGB > > Your effective resolution is different for your 3 channels. Red is only > 3x2, Green is 3x4 and Blue is 3x2. I don't think OIIO has a nice way of > giving you a different resolution per-channel. > > This is also further complicated by the fact that different cameras may > choose completely different "Bayer" patterns, and the mass amount of > complexity over handling those cases is the reason we have to call out to > the LibRaw library in the first place. > > For example, your camera could be storing the channels like this (Fuji > X-Trans): > > GBGGRG > RGRBGB > GBGGRG > GRGGBG > > Now the effective resolution is a lot harder to quantify, as there is a > variable number of samples per row/column. > > https://en.wikipedia.org/wiki/Bayer_filter#Modifications > > In other words there is no more human readable mode, other than by > demosaicing. Any invention of pixel values that OIIO could do would be the > same process as demosaicing. > > Cheers, > Mark > > On Wed, Jul 28, 2021 at 9:19 AM Vlad <libal...@gmail.com> wrote: > >> >> The demosaic none option is specifically requesting no demosaicing to be >> done on the raw data, so your image will be grey scale, and likely still in >> an RGGB "Bayer" pattern. Each "pixel" in this returned image is exactly >> what each photosite captured. >> >> >> Do you mean that RAW data is stored as three blocks with only R only GG >> and only B? >> >> It sounds like it is working as expected, but this mode probably isn't >> useful to you. Demosaicing is a crucial step in raw processing, and there >> are only limited times where you might want to disable it. >> >> >> Probably you right. But always tend to find something unexpected. >> >> But how can I have raw channels in more human readable mode? Is this >> possible give oiio and libraw direction to deliver result at least as >> grayscale pattern? >> RGRGRG >> GBGBGB >> RGRGRG >> GBGBGB >> >> As for the highlight mode issue, the reason your highlights are pink is >> because your green and blue channels have clipped at a lower level than the >> red channel. I have a new mode that I've been meaning to put a merge >> request in for that will try to determine your lowest clipped channel and >> then clamp the other channels to it, but it's not released yet. Note that >> this will lose information from that red channel, but often at such high >> sensor saturation the data is not often useful. >> >> In the mean time you should be able to clamp your images manually, though >> you might need to run them through once to determine what the correct value >> should be. It'll be whichever channel value is lowest in your pink >> highlight areas. >> >> Cheers, >> Mark >> >> On Tue, 27 Jul 2021, 09:13 Vlad, <libal...@gmail.com> wrote: >> >>> >>> >>> On Fri, 23 Jul 2021 at 10:19, Larry Gritz <l...@larrygritz.com> wrote: >>> >>>> These options are all directly passed to the underlying "LibRaw", so >>>> you should consult the LibRaw documentation about what they do and what >>>> values are reasonable for the effects you want. >>>> >>>> As far as Demosaic, if you say "none", I would expect it to give you a >>>> grayscale image, yes. (I have not tried this. I guess it's possible that in >>>> addition to grayscale, is it broken in other ways?) >>>> >>>> >>> Yes, result looks like some bits order is missed. Image looks like image >>> with highly skewed lines and two big top and bottom black borders. >>> >>> >>>> >>>> On Jul 22, 2021, at 1:01 AM, Vlad <libal...@gmail.com> wrote: >>>> >>>> Hi everyone. >>>> >>>> I traying to find a way to use OpenimageIO and RAW plugin to camera raw >>>> image processing. >>>> And some options ro RAW plugin give weird results. >>>> >>>> For example: >>>> oiiotool.exe --iconfig raw:Demosaic none ARW\_DSC4410.ARW -o >>>> ARW\_DSC4410_.TIF >>>> >>>> give me grayscale image that looks like it missed some pixel order. >>>> >>>> raw:Demosaic linear or any other available demosaic options work as >>>> expected. >>>> >>>> >>>> >>>> Another issue i can't figure out because no information on plugin page >>>> in >>>> --iconfig raw:HighlightMode 1 (unclip) >>>> it give me pink color on highlights. >>>> >>>> What i need chose to convert RAW image as Unclipped dynamic range to >>>> int 16 bit or 16/32bit floats? >>>> >>>> Or this issues looks more like a bugs and better report them? >>>> >>>> Best regards >>>> Vlad >>>> _______________________________________________ >>>> Oiio-dev mailing list >>>> Oiio-dev@lists.openimageio.org >>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>> >>>> >>>> -- >>>> Larry Gritz >>>> l...@larrygritz.com >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Oiio-dev mailing list >>>> Oiio-dev@lists.openimageio.org >>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>> >>> _______________________________________________ >>> Oiio-dev mailing list >>> Oiio-dev@lists.openimageio.org >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>> >> _______________________________________________ >> Oiio-dev mailing list >> Oiio-dev@lists.openimageio.org >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> >> _______________________________________________ >> Oiio-dev mailing list >> Oiio-dev@lists.openimageio.org >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> > _______________________________________________ > Oiio-dev mailing list > Oiio-dev@lists.openimageio.org > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > > -- > Larry Gritz > l...@larrygritz.com > > > > > _______________________________________________ > Oiio-dev mailing list > Oiio-dev@lists.openimageio.org > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >
_______________________________________________ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
