Re: [Oiio-dev] converting single part EXR to multi part EXR

[Jonathan Egstad]

Rather than using OIIO you may find it easier to use the ‘exrmultipart’ tool 
that comes with OpenEXR which can combine or separate Parts based on channel 
name keys. It’s certainly easier than using Nuke!

Cheers,
-jonathan


> On May 7, 2021, at 10:29 AM, Matthías Bjarnason  
> wrote:
> 
> Can someone please help explain how one goes about converting EXR (pre 2.0) 
> that includes multiple channels (render engine output AOVs) to a "multi part" 
> EXR, more optimized for reading, using OIIO?
> 
> So far I have been using Foundry's Nuke for this purpose but that is 
> obviously an overkill solution and extremely expensive use of licenses 
> ...which I'd like to be not dependent on if possible.
> 
> By reading the OIIO help, it seems like this is all possible but I can't for 
> the life of me figure out how ...using a simple command. Am I missing 
> something?
> 
> For reference Nuke's output(write) node documentation states:
> 
> Sets the interleave strategy for channels, layers, and views with a rendered 
> .exr file. A single- or multi-part .exr file is created as described by the 
> following options, with layers and parts sorted alphabetically:
> 
> • channels, layers and views - creates a single-part .exr file ensuring 
> backward compatibility with applications that use OpenEXR 1.x.
> 
> • channels and layers - creates a multi-part .exr file with one part per 
> view. This can improve Read performance as Nuke only reads the part 
> associated with the specified view.
> 
> • channels - creates a multi-part .exr with one part per layer.
> 
> 
> It would be both the second and third option scenarios I'm most interested in 
> recreating using OIIO but from what I can gather in the OIIO help, there is 
> no simple flag/command to do this - a simple file IN file OUT.
> 
> 
> Is this at all possible using OIIO's basic tool commands?
> 
> Any help appreciated - thanks.
> 
> - M
> ___
> 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

Re: [Oiio-dev] Auto-trimming Multi-part exrs

[Jonathan Egstad]

For reference here’s the check code in OpenEXR which verifies matching 
displayWindows when you author a MultiPart file:

MultiPartOutputFile::Data::checkSharedAttributesValues() line 408:
  
https://github.com/AcademySoftwareFoundation/openexr/blob/master/OpenEXR/IlmImf/ImfMultiPartOutputFile.cpp
 


As others have said there’s no similar restriction on dataWindows matching and 
it’s the apps reading MultiPart exrs that choke.

-j

> On Feb 24, 2020, at 1:13 PM, Orion Holder-Monk  
> wrote:
> 
> Thanks for the responses. Appreciate the insight.
> 
> For now with the python code, I will look to implement in a similar way to 
> the trim, and possibly move similar sized images into their own multipart 
> image.
> I can also post it to the Foundry and Autodesk and see what they say, but 
> also check some other apps I use gets tripped up by the different display 
> windows.
> 
> Thanks again,
> Orion
> 
> On Tue, 25 Feb 2020 at 8:00 AM, Larry Gritz  wrote:
> It's entirely possible that the reason I implemented oiiotool --trim as the 
> union across parts is because I knew or discovered at the time that there 
> were widely-used apps out there that would get gummed up if the windows 
> didn't match on all the parts.
> 
> The --autotrim issue of only considering the first image is separate and is a 
> true bug, I will fix that right away.
> 
>   -- lg
> 
> 
>> On Feb 24, 2020, at 12:55 PM, Marco Meyer  wrote:
>> 
>> Had a silimar observation when trying creating autotrimmed multiparts and 
>> ultimately stuck with creating a union data window for all subimages so 
>> every app is happy with it.
>> 
>> An interesting thing I noticed was that Beachball multipart example from 
>> openexr 
>> (https://github.com/AcademySoftwareFoundation/openexr-images/tree/master/Beachball)
>> also can't be read in nuke and throws the 'Reader did not set bounding box' 
>> error, because it includes one subimage "whitebarmask.mask" that has a 
>> different data window. 
>> So I while I think openexr itself encourages datawindows per subimage, some 
>> of the apps unfortunately don't know how to handle it.
>>  
>> One could assume the app developers use the official exr examples for the 
>> most basic compatibility testing... but here we are :)
>> 
>> 
>> On Sun, 2020-02-23 at 23:09 -0800, Larry Gritz wrote:
>>> Aha, I see, I believe that oiiotool --autotrim sets the trim based on the 
>>> first subimage (which is definitely wrong and I will fix right away), and 
>>> --trim seems to trim all subimages to the union of the nonzero regions of 
>>> all subimages (suboptimal, see below).
>>> 
>>> It seems as if my assumption on --trim was that the different parts (what 
>>> we call subimages) had to share the same data windows. In rereading the 
>>> openexr docs now, it looks like that is not the case. Does anybody more 
>>> familiar with OpenEXR want to comment?
>>> 
>>> I'm really not sure what's up with RV and Nuke, though, but I wonder if 
>>> they, too, are assuming that the data window will always be the same for 
>>> all parts? (Is anybody from Autodesk or Foundry reading and can check?)
>>> 
>>> Fixing --autotrim to work the same as --trim, rather than incorrectly trim 
>>> all parts to the nonzero portion of the first part, is a no-brainer.
>>> 
>>> However, fixing --trim/--autotrim to trim each part individually... I do 
>>> worry that this might result in files that are unreadable by other apps.
>>> 
>>> -- lg
>>> 
>>> 
 On Feb 23, 2020, at 7:01 PM, Orion Holder-Monk  
 wrote:
 
 Hi Dev team
 
 I've just been trying to implement the auto-trim tool for multi-part exrs 
 from oiiotool in a python set of tools.
 Reason I'm doing it is currently if I was to use oiiotool -i 
 multipart_input.exr -a --autotrim -o multipart_output.exr, it will change 
 all my parts to match the spec of the first part (so cropping to the first 
 images visible pixels and change the data format etc).
 
 My implementation (below) is not raising any errors from oiio, but what 
 happens is that I'm getting an 'incomplete image' warning in RV (although 
 can see each image correctly) and a 'Reader did not set bounding box' 
 error in Nuke.
 
 If I set the crop roi to be consistent for every part instead of unique 
 per part, it creates the image fine and no warnings come up.
 
 Any help or suggestions would be greatly appreciated. (and if there's a 
 simple oiiotool command that I could use as an alternative, please do say)
 And in terms of build, I am using 1.8.7.3, but have tested with 2.1 as 
 well and get the same result.
 The below code if ran as a file will run with `python autotrim.py --input 
 multipart_input.exr --output multipart_output.exr`
 I've also attempted to attach an example file to run it on, but it may be 
 too big.

Re: [Oiio-dev] Deep merge

[Jonathan Egstad]

There’s been good conversations but I’ve not heard back yet on any progress 
except for Mantra. If you’re interested in this functionality I could use the 
help in reaching out (gently pressuring….) vendors like Solid Angle and Foundry 
- so far it’s just been me.

It’s not immediately obvious from the deep subpixel mask paper and the 
opendcx.org web site but the OpenDCX code does not require subpixel masks to be 
present to transform and filter deep images.  The Dcx::DeepTransform class 
resamples the input subpixel masks, but interprets deep pixels lacking mask 
information as ‘full-coverage’ - which is common for volumetric samples which 
don’t really require subpixel masks.

DeepTransform supports partial subpixel-coverage weighting so fractional pixel 
transforms are possible and accurate.  This functionality is currently 
undergoing further refinement but scale/translates that line up with the 8x8 
subpixel mask grid filter accurately with the public  code.


Cheers,
-jonathan

> On Dec 7, 2016, at 12:58 AM, Thorsten Kaufmann 
> <thorsten.kaufm...@mackevision.com> wrote:
> 
> The main problem seems to be renderer support and the lack of information on 
> how to generate the needed subpixel mask from a raytracer. Do you know if 
> there
> was any advances in that area?
>  
> Cheers,
> Thorsten
>  
> ---
> Thorsten Kaufmann
> Production Pipeline Architect
> 
> Mackevision Medien Design GmbH
> Forststraße 7
> 70174 Stuttgart
> 
> T +49 711 93 30 48 661
> F +49 711 93 30 48 90
> M +49 151 19 55 55 02
> 
> thorsten.kaufm...@mackevision.com <mailto:thorsten.kaufm...@mackevision.com>
> www.mackevision.com 
> <http://www.mackevision.com/?utm_source=E-Mail-Signatur_medium=E-Mail_campaign=Mackevision-Link>
> Geschäftsführer: Armin Pohl, Joachim Lincke, Jens Pohl
> HRB 243735 Amtsgericht Stuttgart
> 
> ---
> PORTFOLIO: The Next Level of User Experience - Real-time Solutions 
> <http://www.mackevision.com/portfolio/real-time-solutions/?utm_source=E-Mail-Signatur_medium=E-Mail_campaign=real-time-signatur>
> VFX: Game of Thrones, Season 6 – VFX breakdown 
> <http://www.mackevision.com/references/game-of-thrones-season-6-vfx-breakdown/?utm_source=E-Mail-Signatur_medium=E-Mail_campaign=GoT-S6-vfx-breakdown-Signatur>
> SOCIAL: Follow us on Facebook <https://www.facebook.com/mackevision/>, 
> Twitter <https://twitter.com/Mackevision>, Behance 
> <https://www.behance.net/mackevision> and Vimeo 
> <https://vimeo.com/mackevision>
> From: Oiio-dev [mailto:oiio-dev-boun...@lists.openimageio.org 
> <mailto:oiio-dev-boun...@lists.openimageio.org>] On Behalf Of Jonathan Egstad
> Sent: Dienstag, 6. Dezember 2016 23:24
> To: OpenImageIO developers <oiio-dev@lists.openimageio.org 
> <mailto:oiio-dev@lists.openimageio.org>>
> Subject: Re: [Oiio-dev] Deep merge
>  
> Try out OpenDCX!  :)
> www.opendcx.org <http://www.opendcx.org/>
>  
> 
> On Dec 6, 2016, at 2:17 PM, Larry Gritz <l...@larrygritz.com 
> <mailto:l...@larrygritz.com>> wrote:
> 
> So how does it work in Nuke? Does it just resample using the "closest" pixel?
>  
> It's well known how to combine multiple non-overlapping pixels into a single 
> depth list -- that's what renderers do to turn subsample depth lists into 
> pixel depth lists for deep output. I would assume that a filtered resampling 
> boils down to roughly the same thing (with adjustment for the specific pixel 
> weights). Though I don't pretend to understand what artifacts would result 
> from filtered resampling of a depth image in this way.
>  
>  
> On Dec 6, 2016, at 2:11 PM, Thorsten Kaufmann 
> <thorsten.kaufm...@mackevision.com 
> <mailto:thorsten.kaufm...@mackevision.com>> wrote:
>  
> ​This is far from trivial. There is deep transform in Nuke, but it does not 
> do any filtering and i am not sure there is a meaningful way to do that.
>  
> Cheers,
> Thorsten
>  
> ---
> Thorsten Kaufmann
> Production Pipeline Architect
> Mackevision Medien Design GmbH
> Forststraße 7
> 70174 Stuttgart
> T +49 711 93 30 48 661
> F +49 711 93 30 48 90
> M +49 151 19 55 55 02
> thorsten.kaufm...@mackevision.com <mailto:thorsten.kaufm...@mackevision.com>
> www.mackevision.com 
> <http://www.mackevision.com/?utm_source=E-Mail-Signatur_medium=E-Mail_campaign=Mackevision-Link>
> Geschäftsführer: Armin Pohl, Joachim Lincke, Jens Pohl
> HRB 243735 Amtsgericht Stuttgart
> Von: Oiio-dev <oiio-dev-boun...@lists.openimageio.org 
> <mailto:oiio-dev-boun...@lists.openimageio.org>> im Auftrag von Larry Gritz 
> <l...@larrygritz.com <mailto:l...@larrygritz.com>>
> Gesendet: Dienstag, 6. Dezember 2016 18:34

Re: [Oiio-dev] Deep merge

[Jonathan Egstad]

Try out OpenDCX!  :)
www.opendcx.org


On Dec 6, 2016, at 2:17 PM, Larry Gritz  wrote:

So how does it work in Nuke? Does it just resample using the "closest" pixel?

It's well known how to combine multiple non-overlapping pixels into a single 
depth list -- that's what renderers do to turn subsample depth lists into pixel 
depth lists for deep output. I would assume that a filtered resampling boils 
down to roughly the same thing (with adjustment for the specific pixel 
weights). Though I don't pretend to understand what artifacts would result from 
filtered resampling of a depth image in this way.


> On Dec 6, 2016, at 2:11 PM, Thorsten Kaufmann 
>  wrote:
> 
> ​This is far from trivial. There is deep transform in Nuke, but it does not 
> do any filtering and i am not sure there is a meaningful way to do that.
> 
> Cheers,
> Thorsten
> 
> ---
> Thorsten Kaufmann
> Production Pipeline Architect
> Mackevision Medien Design GmbH
> Forststraße 7
> 70174 Stuttgart
> T +49 711 93 30 48 661
> F +49 711 93 30 48 90
> M +49 151 19 55 55 02
> thorsten.kaufm...@mackevision.com
> www.mackevision.com
> Geschäftsführer: Armin Pohl, Joachim Lincke, Jens Pohl
> HRB 243735 Amtsgericht Stuttgart
> ---
> PORTFOLIO: The Next Level of User Experience - Real-time Solutions
> VFX: Game of Thrones, Season 6 – VFX breakdown
> SOCIAL: Follow us on Facebook, Twitter, Behance and Vimeo
> Von: Oiio-dev  im Auftrag von Larry 
> Gritz 
> Gesendet: Dienstag, 6. Dezember 2016 18:34
> An: OpenImageIO developers
> Betreff: Re: [Oiio-dev] Deep merge
>  
> There's not currently a function in OIIO that does this. Does Nuke have deep 
> resize? I guess it's theoretically possible, though you'd need to do a little 
> math to figure out the right way to combine partial/filtered pixels, where 
> each "pixel" is a list of depth+alpha samples.
> 
> 
>> On Dec 5, 2016, at 11:17 PM, Ben Andersen  wrote:
>> 
>> Also! Are there methods of resampling a deep image?  If my B image is a 
>> different resolution than my A image/the pixel count is different, it would 
>> be nice to still be able to merge them together.
>> 
>> Thanks!
>> Ben
>> 
>>> On Tue, Dec 6, 2016 at 4:23 AM Ben Andersen  wrote:
>>> Hi!
>>> 
>>> I'm looking at wrapping up a deep merge operation using the python bindings 
>>> of oiio 1.7.
>>> 
>>> I see in the docs that there is support for reading and merge deep pixels.  
>>> Is the expected workflow for all deep images to loop over every pixel?  Is 
>>> there a function I've overlooked that might do a deep merge for all samples 
>>> in the image?
>>> 
>>> Wouldn't this mean that it's essentially single threaded to do a deep merge 
>>> in python without setting up the threads myself?
>>> 
>>> Thanks!
>>> Ben
>> ___
>> 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

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

Re: [Oiio-dev] Any Nuke authors out there?

[Jonathan Egstad]

The industry did not evolve in a scientifically rigorous way.  ;)


On May 19, 2016, at 2:43 PM, Larry Gritz <l...@larrygritz.com> wrote:

Yeah, I'm fine with whatever they want to call it internally.

OpenEXR/ImfStandardAttributes.h agrees with me:

//
// xDensity -- horizontal output density, in pixels per inch.
// The image's vertical output density is xDensity * pixelAspectRatio.
//

When I make an exr file with ydensity=xdensity*pixelaspectratio, and a par=2, I 
get a wide image in Nuke.

When I make a JPEG with ydensity=xdensity*pixelaspectratio and par=2, I get a 
skinny image in Nuke.

Nuke's JPEG reader/writer is interpreting the xdensity and ydensity fields as 
sizes, not densities.

But then again, so are PhotoShop, ffmpeg, and rv. OIIO is the only package that 
seems to take the JFIF spec on face value. I don't see how we have much choice 
other than to also be wrong, we certainly can't make files that will come out 
wrong in many VFX apps.


> On May 19, 2016, at 2:21 PM, Jonathan Egstad <jegs...@earthlink.net> wrote:
> 
> If it makes you feel any better, the Nuke notation is based on film 
> terminology where the anamorphic value refers to the projector lens stretch, 
> not the camera lens squeeze.  i.e. 2.0 means x2 in display width.
> 
> Typically anamorphic is not referred to as 0.5...
> 
> -j
> 
> On May 19, 2016, at 1:34 PM, Larry Gritz <l...@larrygritz.com> wrote:
> 
> No, but it doesn't agree after all!
> 
> When I instruct oiiotool to write an OpenEXR with pixel aspect of 2.0, Nuke 
> correctly displays it as wide.
> 
> Same with TIFF.
> 
> But when oiiotool writes a JPEG with pixel aspect of 2.0 -- I *THINK* I'm 
> doing it right, there is no JPEG aspect field, in infers it from the x and y 
> densities (pixels per inch), so I set ydensity = aspect*xdensity -- then Nuke 
> displays it as as skinny rather than wide.
> 
> Apparently, PhotoShop, rv, and ffmpeg all agree with Nuke.
> 
> So it must be me who is wrong here! But for the life of me, I can't figure 
> out from the JFIF spec why the Nuke/rv/ffmpeg/PS interpretation makes sense.
> 
> Either the problem is entirely in my head -- I'm just interpreting the JFIF 
> spec incorrectly -- or else a long time ago somebody got it backwards, and 
> now everybody else is just trying to be compatible despite not agreeing with 
> the spec.
> 
> 
>> On May 19, 2016, at 1:17 PM, Jonathan Egstad <jegs...@earthlink.net> wrote:
>> 
>> (typing on a small iphone atm so I'll check out the thread in more detail 
>> later)
>> 
>> You're correct about what Nuke's format.pixel_aspect() is - it's the 
>> correction factor from pixel-storage to real-world coordinates.
>> So a Nuke format with pa 2.0 is typically an anamorphic image where the 
>> stored pixels are half their real-world width and require stretching out 
>> horizontally when viewed.
>> 
>> As for the jpeg reader/writer I wrote a pa 2.0 checkerboard jpeg out of Nuke 
>> and it displays correctly in ffmpeg's ffplay viewer - i.e. not squished.
>> For reference DWA's internal viewing tool ignores the density vars and 
>> displays a squished image.
>> 
>> So I think you're interpretation is correct in OIIO, and Nuke, RV & ffmpeg 
>> agree with it.
>> 
>> -j
>> 
>> On May 19, 2016, at 10:43 AM, Larry Gritz <l...@larrygritz.com> wrote:
>> 
>> Hi, Jonathan, thanks!
>> 
>> If you could quickly read over the discussion in this PR: 
>> https://github.com/OpenImageIO/oiio/pull/1412
>> 
>> (It's not overly long or technical, but it might make you scratch your head 
>> a bit.)
>> 
>> The question is: Do you know anything about what Nuke is up to in the cited 
>> JPEG code? Do you believe Nuke is computing the aspect ratio for JPEG files 
>> backwards (versus the JFIF spec), or do you think that my interpretation of 
>> JFIF's fields are incorrect?
>> 
>> If Nuke is wrong, does that mean that we'd better do it wrong, too, or be 
>> forever doomed to have the aspect ratio being mangled when Nuke reads our 
>> files or vice versa? Or is there another solution you can think of that 
>> doesn't involve our having to introduce a bug? (I don't imagine that the 
>> Foundry will deem it practical to suddenly change Nuke's interpretation at 
>> this stage, even if it's technically wrong.)
>> 
>> 
>>> On May 19, 2016, at 10:02 AM, Jonathan Egstad <jegs...@earthlink.net> wrote:
>>> 
>>> Hey Larry,
>>> I'm one of the original Nuke authors but not with the Foundry - if you need 
>>> help with general plugin coding questions maybe I can help.
>>> 
>>> Chee

Re: [Oiio-dev] Any Nuke authors out there?

[Jonathan Egstad]

If it makes you feel any better, the Nuke notation is based on film terminology 
where the anamorphic value refers to the projector lens stretch, not the camera 
lens squeeze.  i.e. 2.0 means x2 in display width.

Typically anamorphic is not referred to as 0.5...

-j

On May 19, 2016, at 1:34 PM, Larry Gritz <l...@larrygritz.com> wrote:

No, but it doesn't agree after all!

When I instruct oiiotool to write an OpenEXR with pixel aspect of 2.0, Nuke 
correctly displays it as wide.

Same with TIFF.

But when oiiotool writes a JPEG with pixel aspect of 2.0 -- I *THINK* I'm doing 
it right, there is no JPEG aspect field, in infers it from the x and y 
densities (pixels per inch), so I set ydensity = aspect*xdensity -- then Nuke 
displays it as as skinny rather than wide.

Apparently, PhotoShop, rv, and ffmpeg all agree with Nuke.

So it must be me who is wrong here! But for the life of me, I can't figure out 
from the JFIF spec why the Nuke/rv/ffmpeg/PS interpretation makes sense.

Either the problem is entirely in my head -- I'm just interpreting the JFIF 
spec incorrectly -- or else a long time ago somebody got it backwards, and now 
everybody else is just trying to be compatible despite not agreeing with the 
spec.


> On May 19, 2016, at 1:17 PM, Jonathan Egstad <jegs...@earthlink.net> wrote:
> 
> (typing on a small iphone atm so I'll check out the thread in more detail 
> later)
> 
> You're correct about what Nuke's format.pixel_aspect() is - it's the 
> correction factor from pixel-storage to real-world coordinates.
> So a Nuke format with pa 2.0 is typically an anamorphic image where the 
> stored pixels are half their real-world width and require stretching out 
> horizontally when viewed.
> 
> As for the jpeg reader/writer I wrote a pa 2.0 checkerboard jpeg out of Nuke 
> and it displays correctly in ffmpeg's ffplay viewer - i.e. not squished.
> For reference DWA's internal viewing tool ignores the density vars and 
> displays a squished image.
> 
> So I think you're interpretation is correct in OIIO, and Nuke, RV & ffmpeg 
> agree with it.
> 
> -j
> 
> On May 19, 2016, at 10:43 AM, Larry Gritz <l...@larrygritz.com> wrote:
> 
> Hi, Jonathan, thanks!
> 
> If you could quickly read over the discussion in this PR: 
> https://github.com/OpenImageIO/oiio/pull/1412
> 
> (It's not overly long or technical, but it might make you scratch your head a 
> bit.)
> 
> The question is: Do you know anything about what Nuke is up to in the cited 
> JPEG code? Do you believe Nuke is computing the aspect ratio for JPEG files 
> backwards (versus the JFIF spec), or do you think that my interpretation of 
> JFIF's fields are incorrect?
> 
> If Nuke is wrong, does that mean that we'd better do it wrong, too, or be 
> forever doomed to have the aspect ratio being mangled when Nuke reads our 
> files or vice versa? Or is there another solution you can think of that 
> doesn't involve our having to introduce a bug? (I don't imagine that the 
> Foundry will deem it practical to suddenly change Nuke's interpretation at 
> this stage, even if it's technically wrong.)
> 
> 
>> On May 19, 2016, at 10:02 AM, Jonathan Egstad <jegs...@earthlink.net> wrote:
>> 
>> Hey Larry,
>> I'm one of the original Nuke authors but not with the Foundry - if you need 
>> help with general plugin coding questions maybe I can help.
>> 
>> Cheers,
>> -j
>> 
>> On May 18, 2016, at 10:18 AM, Larry Gritz <l...@larrygritz.com> wrote:
>> 
>> Anybody from the Foundry who works on Nuke reading this?
> 
> --
> 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

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

Re: [Oiio-dev] Any Nuke authors out there?

[Jonathan Egstad]

(typing on a small iphone atm so I'll check out the thread in more detail later)

You're correct about what Nuke's format.pixel_aspect() is - it's the correction 
factor from pixel-storage to real-world coordinates.
So a Nuke format with pa 2.0 is typically an anamorphic image where the stored 
pixels are half their real-world width and require stretching out horizontally 
when viewed.

As for the jpeg reader/writer I wrote a pa 2.0 checkerboard jpeg out of Nuke 
and it displays correctly in ffmpeg's ffplay viewer - i.e. not squished.
For reference DWA's internal viewing tool ignores the density vars and displays 
a squished image.

So I think you're interpretation is correct in OIIO, and Nuke, RV & ffmpeg 
agree with it.

-j

On May 19, 2016, at 10:43 AM, Larry Gritz <l...@larrygritz.com> wrote:

Hi, Jonathan, thanks!

If you could quickly read over the discussion in this PR: 
https://github.com/OpenImageIO/oiio/pull/1412

(It's not overly long or technical, but it might make you scratch your head a 
bit.)

The question is: Do you know anything about what Nuke is up to in the cited 
JPEG code? Do you believe Nuke is computing the aspect ratio for JPEG files 
backwards (versus the JFIF spec), or do you think that my interpretation of 
JFIF's fields are incorrect?

If Nuke is wrong, does that mean that we'd better do it wrong, too, or be 
forever doomed to have the aspect ratio being mangled when Nuke reads our files 
or vice versa? Or is there another solution you can think of that doesn't 
involve our having to introduce a bug? (I don't imagine that the Foundry will 
deem it practical to suddenly change Nuke's interpretation at this stage, even 
if it's technically wrong.)


> On May 19, 2016, at 10:02 AM, Jonathan Egstad <jegs...@earthlink.net> wrote:
> 
> Hey Larry,
> I'm one of the original Nuke authors but not with the Foundry - if you need 
> help with general plugin coding questions maybe I can help.
> 
> Cheers,
> -j
> 
> On May 18, 2016, at 10:18 AM, Larry Gritz <l...@larrygritz.com> wrote:
> 
> Anybody from the Foundry who works on Nuke reading this?

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

Re: [Oiio-dev] Any Nuke authors out there?

[Jonathan Egstad]

Hey Larry,
I'm one of the original Nuke authors but not with the Foundry - if you need 
help with general plugin coding questions maybe I can help.

Cheers,
-j

On May 18, 2016, at 10:18 AM, Larry Gritz  wrote:

Anybody from the Foundry who works on Nuke reading this? 


--
Larry Gritz
l...@larrygritz.com


___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org


Sent from my iPhone
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] Associated alpha in Nuke PNG files

[Jonathan Egstad]

The source for the pngWriter is supplied with Nuke so you can add the unpremult 
option yourself - it’s in the Documentation/NDK/examples folder.

fwiw that plugin is quite old (circa 2003/2004) and predates the Foundry by at 
least 3 years, so the plugin has likely had little production testing outside 
of DD’s limited need for it - i.e. web images with no alpha.

Recommend putting in a feature request to the Foundry to add the unpremult 
option.

-jonathan

On Jul 25, 2014, at 7:32 AM, Mikael Sundell mikael.sund...@gmail.com wrote:

 Hi!
 
 Dare I even ask why people are writing PNG files from Nuke? It's not exactly 
 a VFX-friendly file format.
 
 In this case we use Nuke to prepare production assets for webreviews and 
 distribution.
  
 You can force some kind of conversion with oiiotool. If you have a file that 
 saves as PNG but that somehow you know is already premultiplied, you could 
 try oiiotool --no-autopremult in.png -o outputfile.ext to suppress the 
 premultiplication that would ordinarily happen when reading PNG files, then 
 write to a new file.
 
 Sounds like a plan!
 But you are right, if you assume that Nuke doesn't know if alpha is 
 associated or not, and some nodes assumes it's not and some assume that it 
 is, then the situation can't really be improved other than perhaps a option 
 on the file writer to make it more obvious.
 
 That's what I had in mind too, just a checkbox in the Nuke PNG reader/writer 
 to highlight the potential problem. It's not just the oiio reader that 
 premultiplies, Photoshop and other Adobe products does it too. They force 
 premultiply based on how data should be present according to the PNG 
 specification.
 
 Thanks all!
 
 Mikael
 
 ___
 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] 1.2/1.3 build issues in older gcc and icc

[Jonathan Egstad]

Apologies if this has been addressed already - I'm forwarding some info from 
our build engineers who are having build issues under gcc4.1.2 and icc12.1 on 
64-bit Linux.
Thanks for any suggestions/help.
-snip-

1) src/include/export.h Line 78:
  #if __GNUC__ = 4

If it is newer than 4.1.2 this works, in 4.1.2 we get compile errors.

Larry Gritz explains it here:
http://lists.openimageio.org/pipermail/oiio-dev-openimageio.org/2013-April/005980.html

If it could be changed and rolled into 1.2 specifically, we could pick it up 
off of release branch 1.2 from GitHub, that would be great.


2) libutil/strutil.cpp Line 94:
#ifdef va_copy
va_copy (apsave, ap);
#else
apsave = ap;
#endif

apsave = ap; causes compilation errors under icc12.1-64bit but not gcc:
src/libutil/strutil.cpp(94): error: expression must be a modifiable lvalue
apsave = ap;
...
compilation aborted for src/libutil/strutil.cpp (code 2)

scons: *** [build/opt-debug-icc12.1_64/src/libutil/strutil.os] Error 2


Reversing the variables makes the errors go away, but is this correct?

-snip-

___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] Plugin search path vs. embedded

[Jonathan Egstad]

Hi Larry,

I've finally have a buildable oiio install that I can modify and test.

Your patch does work as advertised and allows me to successfully modify the 
order of the plugin searchpatch and force my custom plugin to be found first by 
changing the 'plugins_override' value.
This is with oiio built with embedded plugins.

Unfortunately my custom plugin still wasn't being instantiated properly and it 
took a bit of digging to figure out why - the embedded plugins contain global 
symbols that get incorporated into libOpenImageIO.so and override the symbols 
in my externally loaded plugin.
For example, the class 'OpenEXRInput' is present in libOpenImageIO.so so the 
static creator routine creates an instance of the embedded class rather than my 
plugin's class, even though the creator routine is being executed in my plugin.

So, I needed to change the names of the classes in the exrinput.cpp  
exroutput.cpp files to avoid this (I also tried namespacing which worked as 
well.)
I also needed to change the declared format name from 'openexr' to 'my_openexr' 
so that it didn't conflict with the map of input_formats from the embedded 
plugins.

I did try changing the dlopen flags and removing RTLD_GLOBAL, but this didn't 
work since the embedded plugins aren't dlopened…

I think namespacing the file plugins or not having their symbols get 
incorporated into the lib would be a cleaner solution, but how to best manage 
that is a bit over my head.


Cheers,

-jonathan


On Jul 29, 2013, at 11:25 AM, Larry Gritz wrote:

 Jonathan, did you get a chance to look at this pull request?  Does that solve 
 any problems for you?
 
   -- lg
 
 
 On Jun 22, 2013, at 9:49 AM, Larry Gritz wrote:
 
 Check out this pull request, and try it out if you have a chance.  I'm 
 curious if it solves the problem for you.
 
 https://github.com/OpenImageIO/oiio/pull/621
 
 
 On Jun 17, 2013, at 4:54 PM, Jonathan Egstad wrote:
 
 Thanks!
 
 -jonathan
 
 On Jun 17, 2013, at 4:22 PM, Larry Gritz wrote:
 
 I think I can make things easier for you on this front.  Let me see what I 
 can throw together.  Stay tuned.
 
 In the mean time, I think you can probably make headway by compiling OIIO 
 with a simple modification to src/libOpenImageIO/CMakeLists.txt -- just 
 comment out line 123 that adds the two exr*.cpp files to the embedded 
 list.  Then it should find your plugin just fine (although it's not a 
 stock libOpenImageIO at that point).
 
-- lg
 
 
 On Jun 17, 2013, at 3:17 PM, Jonathan Egstad wrote:
 
 Without getting into too much detail we've codec modifications to the 
 OpenEXR format that (hopefully soon!) will get rolled in to the standard 
 distribution.  Until then we do need a customized plugin that has small 
 modifications to the codec enumerations and is linked against our OpenEXR 
 build.
 
 So it sounds like our near-term solution is to build oiio without 
 embedded plugins.
 
 However I do think it would be a worthwhile fix if it's trivial enough to 
 do as it would make plugin management more flexible.
 If you don't want to change the API you could trap for a token in the 
 search path like 'builtins:/tmp/oiio/plugins' that would determine 
 where to insert the embedded paths.
 
 -jonathan
 
 On Jun 17, 2013, at 2:06 PM, Larry Gritz wrote:
 
 The idea of the plugins was to extend the set of supported file formats 
 at runtime.  An example would be if an application that uses OIIO wanted 
 to support for GIF files (we don't, natively), they could write their 
 own gif.imageio.so (or .dll) to extend support, rather than create a 
 customized libOpenImageIO.  Another example would be if there was a 
 truly proprietary format (internal to one company, or one application), 
 they could easily extend OIIO to support it just by writing that one 
 DLL/DSO without cluttering the public distribution or without revealing 
 to the world the details of their proprietary format.
 
 (Aside: In truth, although I always thought of the plugin mechanism as 
 an important feature in an image library, it's not clear to me whether 
 anyone at all uses the ability to extend format support at runtime.  I 
 started out with *all* formats supported via DSO/DLL's, even the ones 
 that come with OIIO.  It was user demand that led to format support 
 being embedded in the library rather than DSO's.  People overwhelmingly 
 found the build and distribution simpler with one library rather than a 
 dozen or more plugins.)
 
 I admit that I never really considered the case of somebody who wanted 
 to *replace* an existing format module, rather than extend the set of 
 file formats.  So it's not surprising that the library always considers 
 the built-in (embedded) implementations first, and only checks the 
 DSO/DLL's if none of the embedded readers are able to open the file.
 
 If it's important to you, I think we could fix this pretty easily.  I'm 
 not sure I'd want it to be the default, but we could certainly make it 
 an option to check

Re: [Oiio-dev] Plugin search path vs. embedded

[Jonathan Egstad]

No, sorry Larry, unfortunately it's gotten bogged down in 
third-party-install-purgatory, so I'll likely need to just hack together a test 
myself.

I'll try to get to it this week.

-j


On Jul 29, 2013, at 11:25 AM, Larry Gritz wrote:

 Jonathan, did you get a chance to look at this pull request?  Does that solve 
 any problems for you?
 
   -- lg
 
 
 On Jun 22, 2013, at 9:49 AM, Larry Gritz wrote:
 
 Check out this pull request, and try it out if you have a chance.  I'm 
 curious if it solves the problem for you.
 
 https://github.com/OpenImageIO/oiio/pull/621
 
 
 On Jun 17, 2013, at 4:54 PM, Jonathan Egstad wrote:
 
 Thanks!
 
 -jonathan
 
 On Jun 17, 2013, at 4:22 PM, Larry Gritz wrote:
 
 I think I can make things easier for you on this front.  Let me see what I 
 can throw together.  Stay tuned.
 
 In the mean time, I think you can probably make headway by compiling OIIO 
 with a simple modification to src/libOpenImageIO/CMakeLists.txt -- just 
 comment out line 123 that adds the two exr*.cpp files to the embedded 
 list.  Then it should find your plugin just fine (although it's not a 
 stock libOpenImageIO at that point).
 
-- lg
 
 
 On Jun 17, 2013, at 3:17 PM, Jonathan Egstad wrote:
 
 Without getting into too much detail we've codec modifications to the 
 OpenEXR format that (hopefully soon!) will get rolled in to the standard 
 distribution.  Until then we do need a customized plugin that has small 
 modifications to the codec enumerations and is linked against our OpenEXR 
 build.
 
 So it sounds like our near-term solution is to build oiio without 
 embedded plugins.
 
 However I do think it would be a worthwhile fix if it's trivial enough to 
 do as it would make plugin management more flexible.
 If you don't want to change the API you could trap for a token in the 
 search path like 'builtins:/tmp/oiio/plugins' that would determine 
 where to insert the embedded paths.
 
 -jonathan
 
 On Jun 17, 2013, at 2:06 PM, Larry Gritz wrote:
 
 The idea of the plugins was to extend the set of supported file formats 
 at runtime.  An example would be if an application that uses OIIO wanted 
 to support for GIF files (we don't, natively), they could write their 
 own gif.imageio.so (or .dll) to extend support, rather than create a 
 customized libOpenImageIO.  Another example would be if there was a 
 truly proprietary format (internal to one company, or one application), 
 they could easily extend OIIO to support it just by writing that one 
 DLL/DSO without cluttering the public distribution or without revealing 
 to the world the details of their proprietary format.
 
 (Aside: In truth, although I always thought of the plugin mechanism as 
 an important feature in an image library, it's not clear to me whether 
 anyone at all uses the ability to extend format support at runtime.  I 
 started out with *all* formats supported via DSO/DLL's, even the ones 
 that come with OIIO.  It was user demand that led to format support 
 being embedded in the library rather than DSO's.  People overwhelmingly 
 found the build and distribution simpler with one library rather than a 
 dozen or more plugins.)
 
 I admit that I never really considered the case of somebody who wanted 
 to *replace* an existing format module, rather than extend the set of 
 file formats.  So it's not surprising that the library always considers 
 the built-in (embedded) implementations first, and only checks the 
 DSO/DLL's if none of the embedded readers are able to open the file.
 
 If it's important to you, I think we could fix this pretty easily.  I'm 
 not sure I'd want it to be the default, but we could certainly make it 
 an option to check for DSOs first, i.e., reverse the priority.
 
 Out of curiosity, what does your OpenEXR reader do that the standard one 
 does not?  Is a more productive route to propose an improvement to the 
 built-in exr reader?
 
  -- lg
 
 
 On Jun 17, 2013, at 12:54 PM, Jonathan Egstad wrote:
 
 Sorry if this has been answered before, I can't find a relevant mail.
 
 We've built oiio with embedded plugins and now we're attempting to 
 override the exr plugin with a customized one.
 Unfortunately the plugin_searchpath string passed to 
 ImpageInput::create() does not appear to take precedence during the 
 cataloging of available plugins which means the embedded openexr plugin 
 appears to always be found first.
 
 Is this the expected behavior or am I doing something wrong?
 
 The custom exr plugin is handicapped so the plugin's open() method will 
 produce an assert error, but no assert is occurring so I'm assuming the 
 embedded openexr plugin is getting called instead.
 
 From my reading of imageioplugin.cpp the catalog_all_plugins() method 
 first calls catalog_builtin_plugins() before the searchpath string is 
 being parsed (I haven't yet built oiio with debug prints to see what's 
 going on in there, but that was going to be my next step.)
 
 
 Thanks for any help,
 
 -jonathan

Re: [Oiio-dev] Plugin search path vs. embedded

[Jonathan Egstad]

Thanks Larry,
I'll give it a try and let you know.

-jonathan

On Jun 22, 2013, at 9:49 AM, Larry Gritz wrote:

 Check out this pull request, and try it out if you have a chance.  I'm 
 curious if it solves the problem for you.
 
 https://github.com/OpenImageIO/oiio/pull/621
 
 
 On Jun 17, 2013, at 4:54 PM, Jonathan Egstad wrote:
 
 Thanks!
 
 -jonathan
 
 On Jun 17, 2013, at 4:22 PM, Larry Gritz wrote:
 
 I think I can make things easier for you on this front.  Let me see what I 
 can throw together.  Stay tuned.
 
 In the mean time, I think you can probably make headway by compiling OIIO 
 with a simple modification to src/libOpenImageIO/CMakeLists.txt -- just 
 comment out line 123 that adds the two exr*.cpp files to the embedded list. 
  Then it should find your plugin just fine (although it's not a stock 
 libOpenImageIO at that point).
 
 -- lg
 
 
 On Jun 17, 2013, at 3:17 PM, Jonathan Egstad wrote:
 
 Without getting into too much detail we've codec modifications to the 
 OpenEXR format that (hopefully soon!) will get rolled in to the standard 
 distribution.  Until then we do need a customized plugin that has small 
 modifications to the codec enumerations and is linked against our OpenEXR 
 build.
 
 So it sounds like our near-term solution is to build oiio without embedded 
 plugins.
 
 However I do think it would be a worthwhile fix if it's trivial enough to 
 do as it would make plugin management more flexible.
 If you don't want to change the API you could trap for a token in the 
 search path like 'builtins:/tmp/oiio/plugins' that would determine where 
 to insert the embedded paths.
 
 -jonathan
 
 On Jun 17, 2013, at 2:06 PM, Larry Gritz wrote:
 
 The idea of the plugins was to extend the set of supported file formats 
 at runtime.  An example would be if an application that uses OIIO wanted 
 to support for GIF files (we don't, natively), they could write their own 
 gif.imageio.so (or .dll) to extend support, rather than create a 
 customized libOpenImageIO.  Another example would be if there was a truly 
 proprietary format (internal to one company, or one application), they 
 could easily extend OIIO to support it just by writing that one DLL/DSO 
 without cluttering the public distribution or without revealing to the 
 world the details of their proprietary format.
 
 (Aside: In truth, although I always thought of the plugin mechanism as an 
 important feature in an image library, it's not clear to me whether 
 anyone at all uses the ability to extend format support at runtime.  I 
 started out with *all* formats supported via DSO/DLL's, even the ones 
 that come with OIIO.  It was user demand that led to format support being 
 embedded in the library rather than DSO's.  People overwhelmingly found 
 the build and distribution simpler with one library rather than a dozen 
 or more plugins.)
 
 I admit that I never really considered the case of somebody who wanted to 
 *replace* an existing format module, rather than extend the set of file 
 formats.  So it's not surprising that the library always considers the 
 built-in (embedded) implementations first, and only checks the DSO/DLL's 
 if none of the embedded readers are able to open the file.
 
 If it's important to you, I think we could fix this pretty easily.  I'm 
 not sure I'd want it to be the default, but we could certainly make it an 
 option to check for DSOs first, i.e., reverse the priority.
 
 Out of curiosity, what does your OpenEXR reader do that the standard one 
 does not?  Is a more productive route to propose an improvement to the 
 built-in exr reader?
 
   -- lg
 
 
 On Jun 17, 2013, at 12:54 PM, Jonathan Egstad wrote:
 
 Sorry if this has been answered before, I can't find a relevant mail.
 
 We've built oiio with embedded plugins and now we're attempting to 
 override the exr plugin with a customized one.
 Unfortunately the plugin_searchpath string passed to 
 ImpageInput::create() does not appear to take precedence during the 
 cataloging of available plugins which means the embedded openexr plugin 
 appears to always be found first.
 
 Is this the expected behavior or am I doing something wrong?
 
 The custom exr plugin is handicapped so the plugin's open() method will 
 produce an assert error, but no assert is occurring so I'm assuming the 
 embedded openexr plugin is getting called instead.
 
 From my reading of imageioplugin.cpp the catalog_all_plugins() method 
 first calls catalog_builtin_plugins() before the searchpath string is 
 being parsed (I haven't yet built oiio with debug prints to see what's 
 going on in there, but that was going to be my next step.)
 
 
 Thanks for any help,
 
 -jonathan
 
 
 #include OpenImageIO/imageio.h
 
 using namespace OIIO_NAMESPACE;
 
 const char* plugin_searchpath = /tmp/oiio/plugins;
 const char* read_path = /tmp/oiio/plugins/test.exr;
 
 int main(int argc, char* argv[]) {
 ImageSpec spec;
 ImageInput* reader = ImageInput::create(read_path, plugin_searchpath

Re: [Oiio-dev] Plugin search path vs. embedded

[Jonathan Egstad]

Without getting into too much detail we've codec modifications to the OpenEXR 
format that (hopefully soon!) will get rolled in to the standard distribution.  
Until then we do need a customized plugin that has small modifications to the 
codec enumerations and is linked against our OpenEXR build.

So it sounds like our near-term solution is to build oiio without embedded 
plugins.

However I do think it would be a worthwhile fix if it's trivial enough to do as 
it would make plugin management more flexible.
If you don't want to change the API you could trap for a token in the search 
path like 'builtins:/tmp/oiio/plugins' that would determine where to insert 
the embedded paths.

-jonathan

On Jun 17, 2013, at 2:06 PM, Larry Gritz wrote:

 The idea of the plugins was to extend the set of supported file formats at 
 runtime.  An example would be if an application that uses OIIO wanted to 
 support for GIF files (we don't, natively), they could write their own 
 gif.imageio.so (or .dll) to extend support, rather than create a customized 
 libOpenImageIO.  Another example would be if there was a truly proprietary 
 format (internal to one company, or one application), they could easily 
 extend OIIO to support it just by writing that one DLL/DSO without cluttering 
 the public distribution or without revealing to the world the details of 
 their proprietary format.
 
 (Aside: In truth, although I always thought of the plugin mechanism as an 
 important feature in an image library, it's not clear to me whether anyone at 
 all uses the ability to extend format support at runtime.  I started out with 
 *all* formats supported via DSO/DLL's, even the ones that come with OIIO.  It 
 was user demand that led to format support being embedded in the library 
 rather than DSO's.  People overwhelmingly found the build and distribution 
 simpler with one library rather than a dozen or more plugins.)
 
 I admit that I never really considered the case of somebody who wanted to 
 *replace* an existing format module, rather than extend the set of file 
 formats.  So it's not surprising that the library always considers the 
 built-in (embedded) implementations first, and only checks the DSO/DLL's if 
 none of the embedded readers are able to open the file.
 
 If it's important to you, I think we could fix this pretty easily.  I'm not 
 sure I'd want it to be the default, but we could certainly make it an option 
 to check for DSOs first, i.e., reverse the priority.
 
 Out of curiosity, what does your OpenEXR reader do that the standard one does 
 not?  Is a more productive route to propose an improvement to the built-in 
 exr reader?
 
   -- lg
 
 
 On Jun 17, 2013, at 12:54 PM, Jonathan Egstad wrote:
 
 Sorry if this has been answered before, I can't find a relevant mail.
 
 We've built oiio with embedded plugins and now we're attempting to override 
 the exr plugin with a customized one.
 Unfortunately the plugin_searchpath string passed to ImpageInput::create() 
 does not appear to take precedence during the cataloging of available 
 plugins which means the embedded openexr plugin appears to always be found 
 first.
 
 Is this the expected behavior or am I doing something wrong?
 
 The custom exr plugin is handicapped so the plugin's open() method will 
 produce an assert error, but no assert is occurring so I'm assuming the 
 embedded openexr plugin is getting called instead.
 
 From my reading of imageioplugin.cpp the catalog_all_plugins() method first 
 calls catalog_builtin_plugins() before the searchpath string is being parsed 
 (I haven't yet built oiio with debug prints to see what's going on in there, 
 but that was going to be my next step.)
 
 
 Thanks for any help,
 
 -jonathan
 
 
 #include OpenImageIO/imageio.h
 
 using namespace OIIO_NAMESPACE;
 
 const char* plugin_searchpath = /tmp/oiio/plugins;
 const char* read_path = /tmp/oiio/plugins/test.exr;
 
 int main(int argc, char* argv[]) {
  ImageSpec spec;
  ImageInput* reader = ImageInput::create(read_path, plugin_searchpath);
  if (!reader) return 1;
  if (!reader-open(read_path, spec)) {
 std::cerr  Unable to open file '  read_path  '  std::endl;
 return 1;
  }
 
  std::cout  spec.width  x  spec.height  std::endl;
 
  return 0;
 }
 
 ___
 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

Re: [Oiio-dev] Plugin search path vs. embedded

[Jonathan Egstad]

Thanks!

-jonathan

On Jun 17, 2013, at 4:22 PM, Larry Gritz wrote:

 I think I can make things easier for you on this front.  Let me see what I 
 can throw together.  Stay tuned.
 
 In the mean time, I think you can probably make headway by compiling OIIO 
 with a simple modification to src/libOpenImageIO/CMakeLists.txt -- just 
 comment out line 123 that adds the two exr*.cpp files to the embedded list.  
 Then it should find your plugin just fine (although it's not a stock 
 libOpenImageIO at that point).
 
   -- lg
 
 
 On Jun 17, 2013, at 3:17 PM, Jonathan Egstad wrote:
 
 Without getting into too much detail we've codec modifications to the 
 OpenEXR format that (hopefully soon!) will get rolled in to the standard 
 distribution.  Until then we do need a customized plugin that has small 
 modifications to the codec enumerations and is linked against our OpenEXR 
 build.
 
 So it sounds like our near-term solution is to build oiio without embedded 
 plugins.
 
 However I do think it would be a worthwhile fix if it's trivial enough to do 
 as it would make plugin management more flexible.
 If you don't want to change the API you could trap for a token in the search 
 path like 'builtins:/tmp/oiio/plugins' that would determine where to 
 insert the embedded paths.
 
 -jonathan
 
 On Jun 17, 2013, at 2:06 PM, Larry Gritz wrote:
 
 The idea of the plugins was to extend the set of supported file formats at 
 runtime.  An example would be if an application that uses OIIO wanted to 
 support for GIF files (we don't, natively), they could write their own 
 gif.imageio.so (or .dll) to extend support, rather than create a customized 
 libOpenImageIO.  Another example would be if there was a truly proprietary 
 format (internal to one company, or one application), they could easily 
 extend OIIO to support it just by writing that one DLL/DSO without 
 cluttering the public distribution or without revealing to the world the 
 details of their proprietary format.
 
 (Aside: In truth, although I always thought of the plugin mechanism as an 
 important feature in an image library, it's not clear to me whether anyone 
 at all uses the ability to extend format support at runtime.  I started out 
 with *all* formats supported via DSO/DLL's, even the ones that come with 
 OIIO.  It was user demand that led to format support being embedded in the 
 library rather than DSO's.  People overwhelmingly found the build and 
 distribution simpler with one library rather than a dozen or more plugins.)
 
 I admit that I never really considered the case of somebody who wanted to 
 *replace* an existing format module, rather than extend the set of file 
 formats.  So it's not surprising that the library always considers the 
 built-in (embedded) implementations first, and only checks the DSO/DLL's if 
 none of the embedded readers are able to open the file.
 
 If it's important to you, I think we could fix this pretty easily.  I'm not 
 sure I'd want it to be the default, but we could certainly make it an 
 option to check for DSOs first, i.e., reverse the priority.
 
 Out of curiosity, what does your OpenEXR reader do that the standard one 
 does not?  Is a more productive route to propose an improvement to the 
 built-in exr reader?
 
 -- lg
 
 
 On Jun 17, 2013, at 12:54 PM, Jonathan Egstad wrote:
 
 Sorry if this has been answered before, I can't find a relevant mail.
 
 We've built oiio with embedded plugins and now we're attempting to 
 override the exr plugin with a customized one.
 Unfortunately the plugin_searchpath string passed to ImpageInput::create() 
 does not appear to take precedence during the cataloging of available 
 plugins which means the embedded openexr plugin appears to always be found 
 first.
 
 Is this the expected behavior or am I doing something wrong?
 
 The custom exr plugin is handicapped so the plugin's open() method will 
 produce an assert error, but no assert is occurring so I'm assuming the 
 embedded openexr plugin is getting called instead.
 
 From my reading of imageioplugin.cpp the catalog_all_plugins() method 
 first calls catalog_builtin_plugins() before the searchpath string is 
 being parsed (I haven't yet built oiio with debug prints to see what's 
 going on in there, but that was going to be my next step.)
 
 
 Thanks for any help,
 
 -jonathan
 
 
 #include OpenImageIO/imageio.h
 
 using namespace OIIO_NAMESPACE;
 
 const char* plugin_searchpath = /tmp/oiio/plugins;
 const char* read_path = /tmp/oiio/plugins/test.exr;
 
 int main(int argc, char* argv[]) {
 ImageSpec spec;
 ImageInput* reader = ImageInput::create(read_path, plugin_searchpath);
 if (!reader) return 1;
 if (!reader-open(read_path, spec)) {
   std::cerr  Unable to open file '  read_path  '  std::endl;
   return 1;
 }
 
 std::cout  spec.width  x  spec.height  std::endl;
 
 return 0;
 }
 
 ___
 Oiio-dev mailing list
 Oiio-dev@lists.openimageio.org
 http

Re: [Oiio-dev] Pre-multiplication

[Jonathan Egstad]

fwiw,
Some of the issues with merging HDR pixels have been hashed out in Nuke for a 
while, so a peek at its Merge node may be helpful:

For example 'screen' in Nuke is implemented to avoid the 1-A negative problem:
if (A 0  A1  B0  B1) C = A+B - A*B
else if (A  B) C = A
else C = B

It also has the operation named 'hypot'(hypotenuse) or 'diagonal' which works 
pretty well for HDR pixels:
C = sqrt(A*A + B*B)

And lastly 'geometric':
if (A0  B0) C = 2*A*B / (A+B)
else C = 0

-jonathan

On Jul 13, 2012, at 9:37 AM, Jeremy Selan wrote:

 Yup.
 
 screen =  A+B-AB, where AB term represents the if intersection of the
 subpixel geometry.
 
 But in the case where you have two mattes where you know the
 correlation == -1, (which denotes no overlap in the subpixel
 geometry), adding mattes reduces to a simple A+B.  An example of no
 overlap in the subpixel geometry would be the alpha rasterization of
 two adjacent triangles in a mesh.
 
 So to summarize, if the subpixel geometry has a correlation of 0, the
 math for combining alphas is A+B-AB.  If the correlation is -1, the
 math is A+B.  And for perfectly correlated subpixel geometry?  Sounds
 like a good white-board project for this weekend... Surely there's
 some paper from 1985 that has worked this all out? :)
 
 -- Jeremy
 
 On Thu, Jul 12, 2012 at 9:05 PM, Troy Sobotka troy.sobo...@gmail.com wrote:
 And the inevitable question: What is the canonical compositing formula
 for correlated then? Simple add?
 
 ___
 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