Neato, thanks!
I had never tried asking for demosaic=none before, so never noticed until this
thread that there might be an issue.
-- lg
> On Jul 28, 2021, at 3:28 PM, Mark Boorer <[email protected]> wrote:
>
> 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 <[email protected]
> <mailto:[email protected]>> 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 <[email protected]
>> <mailto:[email protected]>> 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
>> <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 <[email protected]
>> <mailto:[email protected]>> 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, <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>
>>> On Fri, 23 Jul 2021 at 10:19, Larry Gritz <[email protected]
>>> <mailto:[email protected]>> 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 <[email protected]
>>>> <mailto:[email protected]>> 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
>>>> [email protected] <mailto:[email protected]>
>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>
>>> --
>>> Larry Gritz
>>> [email protected] <mailto:[email protected]>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> [email protected] <mailto:[email protected]>
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> [email protected] <mailto:[email protected]>
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> [email protected] <mailto:[email protected]>
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>> _______________________________________________
>> Oiio-dev mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>> _______________________________________________
>> Oiio-dev mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>
> --
> Larry Gritz
> [email protected] <mailto:[email protected]>
>
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> [email protected] <mailto:[email protected]>
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
