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]> 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]
> 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
