Re: [Oiio-dev] oiiotool --quality for dwaa exr ignored

[Larry Gritz]

On Thu, Sep 22, 2016 at 2:15 PM, Larry Gritz  wrote:

> OK, my stab at this is here: https://github.com/OpenImageIO/oiio/pull/1493
>
> Please follow up comments on the approach on that PR, if you don't mind.
>
> It would be great for somebody to pull that patch on their end and give it
> a try (works for me, but would be good to have somebody else confirm it
> meets their expectations).
>


Did anybody get a chance to try this out? I'd like to get this merged today
and push out a release candidate.



>
> On Thu, Sep 22, 2016 at 1:35 AM, Mike Wong | ax.gmail 
> wrote:
>
>> #2 +1
>>
>> On Thu, Sep 22, 2016 at 12:36 AM, Larry Gritz  wrote:
>>
>>
>>> 1. As Kevin points out, we can use something akin to Karl's mapping
>>> (I'll find a cubic curve that maps these smoothly?) of quality's 0-100
>>> scale into settings for DWA compression quality. I don't know if that will
>>> give you a "smooth" response either visually or in terms of file size. If
>>> somebody wants to do a little research and try to map out a more
>>> perceptually or size-wise linear response, please volunteer.
>>>
>>> 2. Another approach is to skip --quality, and just allow the compression
>>> setting to be built into the compression name!  How does this look:
>>> --compression dwaa:45 or --compression dwaa:200. The idea is that anything
>>> starting with "dwaa" would turn on dwaa compression, and any optional
>>> trailing numbers would set the dwaaCompressionQuality.
>>>
>>> Opinions?
>>>
>>>
>>>
>> ___
>> Oiio-dev mailing list
>> Oiio-dev@lists.openimageio.org
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>
>>
>
>
> --
> Larry Gritz
> l...@imageworks.com
>



-- 
Larry Gritz
l...@imageworks.com
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] oiiotool --quality for dwaa exr ignored

[Deke Kincaid]

Yes, keep it as is.

Jason and I are both still slapping our heads for missing the -a :)

On Fri, Sep 23, 2016 at 3:10 PM, Larry Gritz  wrote:

> I *think* that --compression applies to all subimages, because it sets
> some other variable, which is consulted when it's time to output anything.
> It doesn't work by traversing the subimages and setting attributes on each
> one.
>
> So, you're basically just using -a in this circumstance and don't need a
> change?
>
> If there are other things that set attributes that definitely ONLY make
> sense if you do it to all subimages, please do point those out and I'll get
> those fixed.
>
>
>
> On Fri, Sep 23, 2016 at 3:06 PM, Deke Kincaid 
> wrote:
>
>> Ok, I missed seeing the "-a" in there even though it is way at the top
>> :/
>>
>> So I have to walk this back.  We thought about this more after reading
>> your post and there are a bunch of places I wouldn't necessarily want to
>> set an attr on every single subimage:
>>
>> bit depth
>> screen window
>> display window
>> just all around general metadata about the scene which rendered the image
>> (maya file, alembic files, assets in the scene), we only set this in
>> subimage 0, not every subimage as it gets very messy.
>>
>> So as long as --compression: dwaa:10 will set the dwaCompressionLevel
>> attr on every subimages then I'm fine with it.
>>
>>
>>
>> On Thu, Sep 22, 2016 at 10:04 PM, Larry Gritz  wrote:
>>
>>> Yes, I see your point.
>>>
>>> It looks like --compression will work on every part, but by default
>>> --attrib does not.
>>>
>>> oiiotool has a "-a" flag, which means "try to do all operations on all
>>> subimages", and many operations will only operate on the first subimage, if
>>> the -a flag is not used. (There are so many operations where that
>>> *wouldn't* be smart, it's really hard to know what to do in all cases.)
>>>
>>> So, as a temp workaround, you could use -a.
>>>
>>> But, hmmm, how should --attrib work?
>>>
>>> a) As now -- use the "-a" flag if you want it to apply the attribute to
>>> all subimages. But of course, with -a on, you can't do other operations
>>> intentionally to just one subimage (for that invocation of oiiotool, I
>>> mean).
>>>
>>> b) --attrib should ALWAYS do its thing to all subimages.
>>>
>>> c) --attrib should take an optional flag (--attrib:allsubimages=1, say)
>>> to turn it on individually, or if the default is to do it to all subimages,
>>> then an option to not do so. I can't think or any reason at the moment why
>>> you wouldn't want the attribute set on all subimages, but I also can't say
>>> with confidence that it wouldn't break some case I'm not able to recall.
>>>
>>> I'm leaning toward (b), but please try to talk me out of it if you can
>>> think of a reason why this would backfire.
>>>
>>>
>>>
>>> On Thu, Sep 22, 2016 at 7:03 PM, Deke Kincaid 
>>> wrote:
>>>
 One other follow up and also related to the PR. With a multipart EXR
 image, how do you set the compression on all parts?

 It is only setting it on part 0, none of the others are getting
 compressed.  Can we have the --compression dwaa:45 in the above PR also
 work on every single part, not just the first one?  Same with
  --attrib dwaCompressionLevel 45
 it only goes to part 0.




 On Thu, Sep 22, 2016 at 2:15 PM, Larry Gritz  wrote:

> OK, my stab at this is here: https://github.com/OpenI
> mageIO/oiio/pull/1493
>
> Please follow up comments on the approach on that PR, if you don't
> mind.
>
> It would be great for somebody to pull that patch on their end and
> give it a try (works for me, but would be good to have somebody else
> confirm it meets their expectations).
>
>
>
> On Thu, Sep 22, 2016 at 1:35 AM, Mike Wong | ax.gmail <
> artix...@gmail.com> wrote:
>
>> #2 +1
>>
>> On Thu, Sep 22, 2016 at 12:36 AM, Larry Gritz 
>> wrote:
>>
>>
>>> 1. As Kevin points out, we can use something akin to Karl's mapping
>>> (I'll find a cubic curve that maps these smoothly?) of quality's 0-100
>>> scale into settings for DWA compression quality. I don't know if that 
>>> will
>>> give you a "smooth" response either visually or in terms of file size. 
>>> If
>>> somebody wants to do a little research and try to map out a more
>>> perceptually or size-wise linear response, please volunteer.
>>>
>>> 2. Another approach is to skip --quality, and just allow the
>>> compression setting to be built into the compression name!  How does 
>>> this
>>> look: --compression dwaa:45 or --compression dwaa:200. The idea is that
>>> anything starting with "dwaa" would turn on dwaa compression, and any
>>> optional trailing numbers would set the dwaaCompressionQuality.
>>>
>>> Opinions?
>>>

Re: [Oiio-dev] oiiotool --quality for dwaa exr ignored

[Larry Gritz]

I *think* that --compression applies to all subimages, because it sets some
other variable, which is consulted when it's time to output anything. It
doesn't work by traversing the subimages and setting attributes on each one.

So, you're basically just using -a in this circumstance and don't need a
change?

If there are other things that set attributes that definitely ONLY make
sense if you do it to all subimages, please do point those out and I'll get
those fixed.



On Fri, Sep 23, 2016 at 3:06 PM, Deke Kincaid  wrote:

> Ok, I missed seeing the "-a" in there even though it is way at the top :/
>
> So I have to walk this back.  We thought about this more after reading
> your post and there are a bunch of places I wouldn't necessarily want to
> set an attr on every single subimage:
>
> bit depth
> screen window
> display window
> just all around general metadata about the scene which rendered the image
> (maya file, alembic files, assets in the scene), we only set this in
> subimage 0, not every subimage as it gets very messy.
>
> So as long as --compression: dwaa:10 will set the dwaCompressionLevel attr
> on every subimages then I'm fine with it.
>
>
>
> On Thu, Sep 22, 2016 at 10:04 PM, Larry Gritz  wrote:
>
>> Yes, I see your point.
>>
>> It looks like --compression will work on every part, but by default
>> --attrib does not.
>>
>> oiiotool has a "-a" flag, which means "try to do all operations on all
>> subimages", and many operations will only operate on the first subimage, if
>> the -a flag is not used. (There are so many operations where that
>> *wouldn't* be smart, it's really hard to know what to do in all cases.)
>>
>> So, as a temp workaround, you could use -a.
>>
>> But, hmmm, how should --attrib work?
>>
>> a) As now -- use the "-a" flag if you want it to apply the attribute to
>> all subimages. But of course, with -a on, you can't do other operations
>> intentionally to just one subimage (for that invocation of oiiotool, I
>> mean).
>>
>> b) --attrib should ALWAYS do its thing to all subimages.
>>
>> c) --attrib should take an optional flag (--attrib:allsubimages=1, say)
>> to turn it on individually, or if the default is to do it to all subimages,
>> then an option to not do so. I can't think or any reason at the moment why
>> you wouldn't want the attribute set on all subimages, but I also can't say
>> with confidence that it wouldn't break some case I'm not able to recall.
>>
>> I'm leaning toward (b), but please try to talk me out of it if you can
>> think of a reason why this would backfire.
>>
>>
>>
>> On Thu, Sep 22, 2016 at 7:03 PM, Deke Kincaid 
>> wrote:
>>
>>> One other follow up and also related to the PR. With a multipart EXR
>>> image, how do you set the compression on all parts?
>>>
>>> It is only setting it on part 0, none of the others are getting
>>> compressed.  Can we have the --compression dwaa:45 in the above PR also
>>> work on every single part, not just the first one?  Same with
>>>  --attrib dwaCompressionLevel 45
>>> it only goes to part 0.
>>>
>>>
>>>
>>>
>>> On Thu, Sep 22, 2016 at 2:15 PM, Larry Gritz  wrote:
>>>
 OK, my stab at this is here: https://github.com/OpenI
 mageIO/oiio/pull/1493

 Please follow up comments on the approach on that PR, if you don't mind.

 It would be great for somebody to pull that patch on their end and give
 it a try (works for me, but would be good to have somebody else confirm it
 meets their expectations).



 On Thu, Sep 22, 2016 at 1:35 AM, Mike Wong | ax.gmail <
 artix...@gmail.com> wrote:

> #2 +1
>
> On Thu, Sep 22, 2016 at 12:36 AM, Larry Gritz 
> wrote:
>
>
>> 1. As Kevin points out, we can use something akin to Karl's mapping
>> (I'll find a cubic curve that maps these smoothly?) of quality's 0-100
>> scale into settings for DWA compression quality. I don't know if that 
>> will
>> give you a "smooth" response either visually or in terms of file size. If
>> somebody wants to do a little research and try to map out a more
>> perceptually or size-wise linear response, please volunteer.
>>
>> 2. Another approach is to skip --quality, and just allow the
>> compression setting to be built into the compression name!  How does this
>> look: --compression dwaa:45 or --compression dwaa:200. The idea is that
>> anything starting with "dwaa" would turn on dwaa compression, and any
>> optional trailing numbers would set the dwaaCompressionQuality.
>>
>> Opinions?
>>
>>
>>
> ___
> Oiio-dev mailing list
> Oiio-dev@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
>


 --
 Larry Gritz
 l...@imageworks.com

 

Re: [Oiio-dev] oiiotool --quality for dwaa exr ignored

[Deke Kincaid]

Ok, I missed seeing the "-a" in there even though it is way at the top :/

So I have to walk this back.  We thought about this more after reading your
post and there are a bunch of places I wouldn't necessarily want to set an
attr on every single subimage:

bit depth
screen window
display window
just all around general metadata about the scene which rendered the image
(maya file, alembic files, assets in the scene), we only set this in
subimage 0, not every subimage as it gets very messy.

So as long as --compression: dwaa:10 will set the dwaCompressionLevel attr
on every subimages then I'm fine with it.



On Thu, Sep 22, 2016 at 10:04 PM, Larry Gritz  wrote:

> Yes, I see your point.
>
> It looks like --compression will work on every part, but by default
> --attrib does not.
>
> oiiotool has a "-a" flag, which means "try to do all operations on all
> subimages", and many operations will only operate on the first subimage, if
> the -a flag is not used. (There are so many operations where that
> *wouldn't* be smart, it's really hard to know what to do in all cases.)
>
> So, as a temp workaround, you could use -a.
>
> But, hmmm, how should --attrib work?
>
> a) As now -- use the "-a" flag if you want it to apply the attribute to
> all subimages. But of course, with -a on, you can't do other operations
> intentionally to just one subimage (for that invocation of oiiotool, I
> mean).
>
> b) --attrib should ALWAYS do its thing to all subimages.
>
> c) --attrib should take an optional flag (--attrib:allsubimages=1, say) to
> turn it on individually, or if the default is to do it to all subimages,
> then an option to not do so. I can't think or any reason at the moment why
> you wouldn't want the attribute set on all subimages, but I also can't say
> with confidence that it wouldn't break some case I'm not able to recall.
>
> I'm leaning toward (b), but please try to talk me out of it if you can
> think of a reason why this would backfire.
>
>
>
> On Thu, Sep 22, 2016 at 7:03 PM, Deke Kincaid 
> wrote:
>
>> One other follow up and also related to the PR. With a multipart EXR
>> image, how do you set the compression on all parts?
>>
>> It is only setting it on part 0, none of the others are getting
>> compressed.  Can we have the --compression dwaa:45 in the above PR also
>> work on every single part, not just the first one?  Same with
>>  --attrib dwaCompressionLevel 45
>> it only goes to part 0.
>>
>>
>>
>>
>> On Thu, Sep 22, 2016 at 2:15 PM, Larry Gritz  wrote:
>>
>>> OK, my stab at this is here: https://github.com/OpenI
>>> mageIO/oiio/pull/1493
>>>
>>> Please follow up comments on the approach on that PR, if you don't mind.
>>>
>>> It would be great for somebody to pull that patch on their end and give
>>> it a try (works for me, but would be good to have somebody else confirm it
>>> meets their expectations).
>>>
>>>
>>>
>>> On Thu, Sep 22, 2016 at 1:35 AM, Mike Wong | ax.gmail <
>>> artix...@gmail.com> wrote:
>>>
 #2 +1

 On Thu, Sep 22, 2016 at 12:36 AM, Larry Gritz 
 wrote:


> 1. As Kevin points out, we can use something akin to Karl's mapping
> (I'll find a cubic curve that maps these smoothly?) of quality's 0-100
> scale into settings for DWA compression quality. I don't know if that will
> give you a "smooth" response either visually or in terms of file size. If
> somebody wants to do a little research and try to map out a more
> perceptually or size-wise linear response, please volunteer.
>
> 2. Another approach is to skip --quality, and just allow the
> compression setting to be built into the compression name!  How does this
> look: --compression dwaa:45 or --compression dwaa:200. The idea is that
> anything starting with "dwaa" would turn on dwaa compression, and any
> optional trailing numbers would set the dwaaCompressionQuality.
>
> Opinions?
>
>
>
 ___
 Oiio-dev mailing list
 Oiio-dev@lists.openimageio.org
 http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org


>>>
>>>
>>> --
>>> Larry Gritz
>>> l...@imageworks.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...@imageworks.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

Re: [Oiio-dev] oiiotool --quality for dwaa exr ignored

[Karl Rasche]

If its not explictly set, 45 will be used in IImImf.

But Id have to check the code to see if dwaCompressionLevel gets explictly
added if its omitted. My guess is that it isnt added automagically.

On Thursday, September 22, 2016, Deke Kincaid  wrote:

> One more.  When you don't set the compression at all, the compression attr
> does not get set, so I'm not even sure if this is a "legal" dwa compressed
> file?
>
> Shouldn't we default to 45 if nothing is set?
>
> On Thu, Sep 22, 2016 at 7:03 PM, Deke Kincaid  > wrote:
>
>> One other follow up and also related to the PR. With a multipart EXR
>> image, how do you set the compression on all parts?
>>
>> It is only setting it on part 0, none of the others are getting
>> compressed.  Can we have the --compression dwaa:45 in the above PR also
>> work on every single part, not just the first one?  Same with
>>  --attrib dwaCompressionLevel 45
>> it only goes to part 0.
>>
>>
>>
>>
>> On Thu, Sep 22, 2016 at 2:15 PM, Larry Gritz > > wrote:
>>
>>> OK, my stab at this is here: https://github.com/OpenI
>>> mageIO/oiio/pull/1493
>>>
>>> Please follow up comments on the approach on that PR, if you don't mind.
>>>
>>> It would be great for somebody to pull that patch on their end and give
>>> it a try (works for me, but would be good to have somebody else confirm it
>>> meets their expectations).
>>>
>>>
>>>
>>> On Thu, Sep 22, 2016 at 1:35 AM, Mike Wong | ax.gmail <
>>> artix...@gmail.com >
>>> wrote:
>>>
 #2 +1

 On Thu, Sep 22, 2016 at 12:36 AM, Larry Gritz > wrote:


> 1. As Kevin points out, we can use something akin to Karl's mapping
> (I'll find a cubic curve that maps these smoothly?) of quality's 0-100
> scale into settings for DWA compression quality. I don't know if that will
> give you a "smooth" response either visually or in terms of file size. If
> somebody wants to do a little research and try to map out a more
> perceptually or size-wise linear response, please volunteer.
>
> 2. Another approach is to skip --quality, and just allow the
> compression setting to be built into the compression name!  How does this
> look: --compression dwaa:45 or --compression dwaa:200. The idea is that
> anything starting with "dwaa" would turn on dwaa compression, and any
> optional trailing numbers would set the dwaaCompressionQuality.
>
> Opinions?
>
>
>
 ___
 Oiio-dev mailing list
 Oiio-dev@lists.openimageio.org
 
 http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org


>>>
>>>
>>> --
>>> Larry Gritz
>>> l...@imageworks.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] oiiotool --quality for dwaa exr ignored

[Larry Gritz]

Yes, I see your point.

It looks like --compression will work on every part, but by default
--attrib does not.

oiiotool has a "-a" flag, which means "try to do all operations on all
subimages", and many operations will only operate on the first subimage, if
the -a flag is not used. (There are so many operations where that
*wouldn't* be smart, it's really hard to know what to do in all cases.)

So, as a temp workaround, you could use -a.

But, hmmm, how should --attrib work?

a) As now -- use the "-a" flag if you want it to apply the attribute to all
subimages. But of course, with -a on, you can't do other operations
intentionally to just one subimage (for that invocation of oiiotool, I
mean).

b) --attrib should ALWAYS do its thing to all subimages.

c) --attrib should take an optional flag (--attrib:allsubimages=1, say) to
turn it on individually, or if the default is to do it to all subimages,
then an option to not do so. I can't think or any reason at the moment why
you wouldn't want the attribute set on all subimages, but I also can't say
with confidence that it wouldn't break some case I'm not able to recall.

I'm leaning toward (b), but please try to talk me out of it if you can
think of a reason why this would backfire.



On Thu, Sep 22, 2016 at 7:03 PM, Deke Kincaid  wrote:

> One other follow up and also related to the PR. With a multipart EXR
> image, how do you set the compression on all parts?
>
> It is only setting it on part 0, none of the others are getting
> compressed.  Can we have the --compression dwaa:45 in the above PR also
> work on every single part, not just the first one?  Same with
>  --attrib dwaCompressionLevel 45
> it only goes to part 0.
>
>
>
>
> On Thu, Sep 22, 2016 at 2:15 PM, Larry Gritz  wrote:
>
>> OK, my stab at this is here: https://github.com/OpenI
>> mageIO/oiio/pull/1493
>>
>> Please follow up comments on the approach on that PR, if you don't mind.
>>
>> It would be great for somebody to pull that patch on their end and give
>> it a try (works for me, but would be good to have somebody else confirm it
>> meets their expectations).
>>
>>
>>
>> On Thu, Sep 22, 2016 at 1:35 AM, Mike Wong | ax.gmail > > wrote:
>>
>>> #2 +1
>>>
>>> On Thu, Sep 22, 2016 at 12:36 AM, Larry Gritz  wrote:
>>>
>>>
 1. As Kevin points out, we can use something akin to Karl's mapping
 (I'll find a cubic curve that maps these smoothly?) of quality's 0-100
 scale into settings for DWA compression quality. I don't know if that will
 give you a "smooth" response either visually or in terms of file size. If
 somebody wants to do a little research and try to map out a more
 perceptually or size-wise linear response, please volunteer.

 2. Another approach is to skip --quality, and just allow the
 compression setting to be built into the compression name!  How does this
 look: --compression dwaa:45 or --compression dwaa:200. The idea is that
 anything starting with "dwaa" would turn on dwaa compression, and any
 optional trailing numbers would set the dwaaCompressionQuality.

 Opinions?



>>> ___
>>> Oiio-dev mailing list
>>> Oiio-dev@lists.openimageio.org
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>
>>>
>>
>>
>> --
>> Larry Gritz
>> l...@imageworks.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...@imageworks.com
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] oiiotool --quality for dwaa exr ignored

[Larry Gritz]

um... is it required to set dwaCompressionLevel? No default in the library?

OK, I will take no chances. Amending the PR to set to 45 if it's not set
already (and one of the dwa compression modes is requested).


On Thu, Sep 22, 2016 at 7:43 PM, Deke Kincaid  wrote:

> One more.  When you don't set the compression at all, the compression attr
> does not get set, so I'm not even sure if this is a "legal" dwa compressed
> file?
>
> Shouldn't we default to 45 if nothing is set?
>
> On Thu, Sep 22, 2016 at 7:03 PM, Deke Kincaid 
> wrote:
>
>> One other follow up and also related to the PR. With a multipart EXR
>> image, how do you set the compression on all parts?
>>
>> It is only setting it on part 0, none of the others are getting
>> compressed.  Can we have the --compression dwaa:45 in the above PR also
>> work on every single part, not just the first one?  Same with
>>  --attrib dwaCompressionLevel 45
>> it only goes to part 0.
>>
>>
>>
>>
>> On Thu, Sep 22, 2016 at 2:15 PM, Larry Gritz  wrote:
>>
>>> OK, my stab at this is here: https://github.com/OpenI
>>> mageIO/oiio/pull/1493
>>>
>>> Please follow up comments on the approach on that PR, if you don't mind.
>>>
>>> It would be great for somebody to pull that patch on their end and give
>>> it a try (works for me, but would be good to have somebody else confirm it
>>> meets their expectations).
>>>
>>>
>>>
>>> On Thu, Sep 22, 2016 at 1:35 AM, Mike Wong | ax.gmail <
>>> artix...@gmail.com> wrote:
>>>
 #2 +1

 On Thu, Sep 22, 2016 at 12:36 AM, Larry Gritz 
 wrote:


> 1. As Kevin points out, we can use something akin to Karl's mapping
> (I'll find a cubic curve that maps these smoothly?) of quality's 0-100
> scale into settings for DWA compression quality. I don't know if that will
> give you a "smooth" response either visually or in terms of file size. If
> somebody wants to do a little research and try to map out a more
> perceptually or size-wise linear response, please volunteer.
>
> 2. Another approach is to skip --quality, and just allow the
> compression setting to be built into the compression name!  How does this
> look: --compression dwaa:45 or --compression dwaa:200. The idea is that
> anything starting with "dwaa" would turn on dwaa compression, and any
> optional trailing numbers would set the dwaaCompressionQuality.
>
> Opinions?
>
>
>
 ___
 Oiio-dev mailing list
 Oiio-dev@lists.openimageio.org
 http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org


>>>
>>>
>>> --
>>> Larry Gritz
>>> l...@imageworks.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...@imageworks.com
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] oiiotool --quality for dwaa exr ignored

[Deke Kincaid]

One other follow up and also related to the PR. With a multipart EXR image,
how do you set the compression on all parts?

It is only setting it on part 0, none of the others are getting
compressed.  Can we have the --compression dwaa:45 in the above PR also
work on every single part, not just the first one?  Same with
 --attrib dwaCompressionLevel 45
it only goes to part 0.




On Thu, Sep 22, 2016 at 2:15 PM, Larry Gritz  wrote:

> OK, my stab at this is here: https://github.com/OpenImageIO/oiio/pull/1493
>
> Please follow up comments on the approach on that PR, if you don't mind.
>
> It would be great for somebody to pull that patch on their end and give it
> a try (works for me, but would be good to have somebody else confirm it
> meets their expectations).
>
>
>
> On Thu, Sep 22, 2016 at 1:35 AM, Mike Wong | ax.gmail 
> wrote:
>
>> #2 +1
>>
>> On Thu, Sep 22, 2016 at 12:36 AM, Larry Gritz  wrote:
>>
>>
>>> 1. As Kevin points out, we can use something akin to Karl's mapping
>>> (I'll find a cubic curve that maps these smoothly?) of quality's 0-100
>>> scale into settings for DWA compression quality. I don't know if that will
>>> give you a "smooth" response either visually or in terms of file size. If
>>> somebody wants to do a little research and try to map out a more
>>> perceptually or size-wise linear response, please volunteer.
>>>
>>> 2. Another approach is to skip --quality, and just allow the compression
>>> setting to be built into the compression name!  How does this look:
>>> --compression dwaa:45 or --compression dwaa:200. The idea is that anything
>>> starting with "dwaa" would turn on dwaa compression, and any optional
>>> trailing numbers would set the dwaaCompressionQuality.
>>>
>>> Opinions?
>>>
>>>
>>>
>> ___
>> Oiio-dev mailing list
>> Oiio-dev@lists.openimageio.org
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>
>>
>
>
> --
> Larry Gritz
> l...@imageworks.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] oiiotool --quality for dwaa exr ignored

[Larry Gritz]

OK, my stab at this is here: https://github.com/OpenImageIO/oiio/pull/1493

Please follow up comments on the approach on that PR, if you don't mind.

It would be great for somebody to pull that patch on their end and give it
a try (works for me, but would be good to have somebody else confirm it
meets their expectations).



On Thu, Sep 22, 2016 at 1:35 AM, Mike Wong | ax.gmail 
wrote:

> #2 +1
>
> On Thu, Sep 22, 2016 at 12:36 AM, Larry Gritz  wrote:
>
>
>> 1. As Kevin points out, we can use something akin to Karl's mapping (I'll
>> find a cubic curve that maps these smoothly?) of quality's 0-100 scale into
>> settings for DWA compression quality. I don't know if that will give you a
>> "smooth" response either visually or in terms of file size. If somebody
>> wants to do a little research and try to map out a more perceptually or
>> size-wise linear response, please volunteer.
>>
>> 2. Another approach is to skip --quality, and just allow the compression
>> setting to be built into the compression name!  How does this look:
>> --compression dwaa:45 or --compression dwaa:200. The idea is that anything
>> starting with "dwaa" would turn on dwaa compression, and any optional
>> trailing numbers would set the dwaaCompressionQuality.
>>
>> Opinions?
>>
>>
>>
> ___
> Oiio-dev mailing list
> Oiio-dev@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
>


-- 
Larry Gritz
l...@imageworks.com
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] oiiotool --quality for dwaa exr ignored

[Mike Wong | ax.gmail]

#2 +1

On Thu, Sep 22, 2016 at 12:36 AM, Larry Gritz  wrote:


> 1. As Kevin points out, we can use something akin to Karl's mapping (I'll
> find a cubic curve that maps these smoothly?) of quality's 0-100 scale into
> settings for DWA compression quality. I don't know if that will give you a
> "smooth" response either visually or in terms of file size. If somebody
> wants to do a little research and try to map out a more perceptually or
> size-wise linear response, please volunteer.
>
> 2. Another approach is to skip --quality, and just allow the compression
> setting to be built into the compression name!  How does this look:
> --compression dwaa:45 or --compression dwaa:200. The idea is that anything
> starting with "dwaa" would turn on dwaa compression, and any optional
> trailing numbers would set the dwaaCompressionQuality.
>
> Opinions?
>
>
>
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] oiiotool --quality for dwaa exr ignored

[Michel Lerenard]

Also agree on #2.

On 09/21/2016 11:50 PM, Jep Hill wrote:

I second the vote for #2

On Sep 21, 2016, at 9:59 AM, Deke Kincaid > wrote:



I like #2.

On Wed, Sep 21, 2016 at 9:36 AM, Larry Gritz > wrote:


So in following the spirit of OIIO's core mission to allow a
single generic API to shield users from the gory details of each
individual format (as much as possible), I feel strongly that
--quality should not magically change directions and scales for
one format. If --quality 100 is "looks perfect" and lower numbers
mean "smaller files, bigger artifacts" for every other format, it
shouldn't be that for exr, 45 is perfect and larger numbers mean
smaller files. Also, it leads to confusing errors if you set the
"CompressionQuality" in an image metadata and then try to output
it to multiple files of different file formats.

That's why quality is basically ignored for dwaa and instead you
can set the "openexr:dwaCompressionQuality" attribute -- it's
possible to set it, and the name communicates clearly that you
are making a peculiar format-specific adjustment (that will be
ignored by other format writers, if the same output is sent to a
different file).

OK, but I do see that this is awkward and verbose. So I'll
propose two alternatives, and am happy to go with whichever
people want:

1. As Kevin points out, we can use something akin to Karl's
mapping (I'll find a cubic curve that maps these smoothly?) of
quality's 0-100 scale into settings for DWA compression quality.
I don't know if that will give you a "smooth" response either
visually or in terms of file size. If somebody wants to do a
little research and try to map out a more perceptually or
size-wise linear response, please volunteer.

2. Another approach is to skip --quality, and just allow the
compression setting to be built into the compression name!  How
does this look: --compression dwaa:45 or --compression dwaa:200.
The idea is that anything starting with "dwaa" would turn on dwaa
compression, and any optional trailing numbers would set the
dwaaCompressionQuality.

Opinions?



On Wed, Sep 21, 2016 at 8:15 AM, Deke Kincaid
> wrote:

If the constraint of —quality is that it is always 0-100,
then that is going to be hard to map and would lead to
confusion(i.e. All other applications would use a different
slider then oiio). Is it possible to make the quality slider
more contextual to the compression rather then normalizing it
to always be 0-100?

On Tue, Sep 20, 2016 at 11:49 PM, Larry Gritz
 wrote:

maketx doesn't have a --quality command at all, primarily
because we'd traditionally been using either lossless
TIFF or OpenEXR for textures, and for neither of those
did quality come into play.

But recently we added support for TIFF-with-jpeg, and
OpenEXR with DWAA compression has since come along and
looks useful, so if you think that a --quality flag for
maketx is helpful, we can add it.

The real problem is that quality is assumed to be 0-100,
with 100 meaning lossless. It works well for JPEG, which
is the prototypical example. But I wasn't sure how to
make it map to the dwa compression level without being
confusing (dwa compression is an open ended scale, and
higher numbers mean more compression).

I'm perfectly happy to entertain requests to change it,
if there's consensus. For example, if somebody wants to
propose an intuitive and helpful mapping of the 0-100
scale of Quality into the appropriate
dwaCompressionLevel, I think that might be useful.

As you've seen, you can set the compression levels for
dwaa and dwab by setting the
"openexr:dwaCompressionLevel" attribute. It's not hooked
up to the "--quality" only because, ad just mentioned, it
wasn't obvious how that mapping should work.




> On Sep 20, 2016, at 3:11 PM, Deke Kincaid
 wrote:
>
> Hi Larry
>
> We are trying to compress EXR files in OIIO with
dwaa/dwab compression but currently this does not seem to
directly hooked up to the --quality flag in oiiotool.  No
matter if you use --quality 10 or 100, the attr
dwaCompressionLevel key never gets set and the file is
exactly the same size.
>
> We found that we need to directly set the attr via:

Re: [Oiio-dev] oiiotool --quality for dwaa exr ignored

[Larry Gritz]

test message -- ignore

On Wed, Sep 21, 2016 at 2:50 PM, Jep Hill  wrote:

> I second the vote for #2
>
> On Sep 21, 2016, at 9:59 AM, Deke Kincaid  wrote:
>
> I like #2.
>
> On Wed, Sep 21, 2016 at 9:36 AM, Larry Gritz  wrote:
>
>> So in following the spirit of OIIO's core mission to allow a single
>> generic API to shield users from the gory details of each individual format
>> (as much as possible), I feel strongly that --quality should not magically
>> change directions and scales for one format. If --quality 100 is "looks
>> perfect" and lower numbers mean "smaller files, bigger artifacts" for every
>> other format, it shouldn't be that for exr, 45 is perfect and larger
>> numbers mean smaller files. Also, it leads to confusing errors if you set
>> the "CompressionQuality" in an image metadata and then try to output it to
>> multiple files of different file formats.
>>
>> That's why quality is basically ignored for dwaa and instead you can set
>> the "openexr:dwaCompressionQuality" attribute -- it's possible to set
>> it, and the name communicates clearly that you are making a peculiar
>> format-specific adjustment (that will be ignored by other format writers,
>> if the same output is sent to a different file).
>>
>> OK, but I do see that this is awkward and verbose. So I'll propose two
>> alternatives, and am happy to go with whichever people want:
>>
>> 1. As Kevin points out, we can use something akin to Karl's mapping (I'll
>> find a cubic curve that maps these smoothly?) of quality's 0-100 scale into
>> settings for DWA compression quality. I don't know if that will give you a
>> "smooth" response either visually or in terms of file size. If somebody
>> wants to do a little research and try to map out a more perceptually or
>> size-wise linear response, please volunteer.
>>
>> 2. Another approach is to skip --quality, and just allow the compression
>> setting to be built into the compression name!  How does this look:
>> --compression dwaa:45 or --compression dwaa:200. The idea is that anything
>> starting with "dwaa" would turn on dwaa compression, and any optional
>> trailing numbers would set the dwaaCompressionQuality.
>>
>> Opinions?
>>
>>
>>
>> On Wed, Sep 21, 2016 at 8:15 AM, Deke Kincaid 
>> wrote:
>>
>>> If the constraint of —quality is that it is always 0-100, then that is
>>> going to be hard to map and would lead to confusion(i.e. All other
>>> applications would use a different slider then oiio).  Is it possible to
>>> make the quality slider more contextual to the compression rather then
>>> normalizing it to always be 0-100?
>>>
>>> On Tue, Sep 20, 2016 at 11:49 PM, Larry Gritz  wrote:
>>>
 maketx doesn't have a --quality command at all, primarily because we'd
 traditionally been using either lossless TIFF or OpenEXR for textures, and
 for neither of those did quality come into play.

 But recently we added support for TIFF-with-jpeg, and OpenEXR with DWAA
 compression has since come along and looks useful, so if you think that a
 --quality flag for maketx is helpful, we can add it.

 The real problem is that quality is assumed to be 0-100, with 100
 meaning lossless. It works well for JPEG, which is the prototypical
 example. But I wasn't sure how to make it map to the dwa compression level
 without being confusing (dwa compression is an open ended scale, and higher
 numbers mean more compression).

 I'm perfectly happy to entertain requests to change it, if there's
 consensus. For example, if somebody wants to propose an intuitive and
 helpful mapping of the 0-100 scale of Quality into the appropriate
 dwaCompressionLevel, I think that might be useful.

 As you've seen, you can set the compression levels for dwaa and dwab by
 setting the "openexr:dwaCompressionLevel" attribute. It's not hooked up to
 the "--quality" only because, ad just mentioned, it wasn't obvious how that
 mapping should work.




 > On Sep 20, 2016, at 3:11 PM, Deke Kincaid 
 wrote:
 >
 > Hi Larry
 >
 > We are trying to compress EXR files in OIIO with dwaa/dwab
 compression but currently this does not seem to directly hooked up to the
 --quality flag in oiiotool.  No matter if you use --quality 10 or 100, the
 attr dwaCompressionLevel key never gets set and the file is exactly the
 same size.
 >
 > We found that we need to directly set the attr via:
 > oiiotool blah.exr --ch R,G,B --croptofull --compression dwaa --attrib
 dwaCompressionLevel 100.0 -o blah_dwa.exr
 >
 > Any chance we could get this attr hooked up to the quality slider?
 Also it appears that maketx does not have a --quality flag either (I
 haven't checked iconvert).
 >
 > -deke
 >
 >
 > 

Re: [Oiio-dev] oiiotool --quality for dwaa exr ignored

[Jep Hill]

I second the vote for #2

On Sep 21, 2016, at 9:59 AM, Deke Kincaid  wrote:

> I like #2. 
> 
>> On Wed, Sep 21, 2016 at 9:36 AM, Larry Gritz  wrote:
>> So in following the spirit of OIIO's core mission to allow a single generic 
>> API to shield users from the gory details of each individual format (as much 
>> as possible), I feel strongly that --quality should not magically change 
>> directions and scales for one format. If --quality 100 is "looks perfect" 
>> and lower numbers mean "smaller files, bigger artifacts" for every other 
>> format, it shouldn't be that for exr, 45 is perfect and larger numbers mean 
>> smaller files. Also, it leads to confusing errors if you set the 
>> "CompressionQuality" in an image metadata and then try to output it to 
>> multiple files of different file formats.
>> 
>> That's why quality is basically ignored for dwaa and instead you can set the 
>> "openexr:dwaCompressionQuality" attribute -- it's possible to set it, and 
>> the name communicates clearly that you are making a peculiar format-specific 
>> adjustment (that will be ignored by other format writers, if the same output 
>> is sent to a different file).
>> 
>> OK, but I do see that this is awkward and verbose. So I'll propose two 
>> alternatives, and am happy to go with whichever people want:
>> 
>> 1. As Kevin points out, we can use something akin to Karl's mapping (I'll 
>> find a cubic curve that maps these smoothly?) of quality's 0-100 scale into 
>> settings for DWA compression quality. I don't know if that will give you a 
>> "smooth" response either visually or in terms of file size. If somebody 
>> wants to do a little research and try to map out a more perceptually or 
>> size-wise linear response, please volunteer.
>> 
>> 2. Another approach is to skip --quality, and just allow the compression 
>> setting to be built into the compression name!  How does this look: 
>> --compression dwaa:45 or --compression dwaa:200. The idea is that anything 
>> starting with "dwaa" would turn on dwaa compression, and any optional 
>> trailing numbers would set the dwaaCompressionQuality.
>> 
>> Opinions?
>> 
>> 
>> 
>>> On Wed, Sep 21, 2016 at 8:15 AM, Deke Kincaid  wrote:
>>> If the constraint of —quality is that it is always 0-100, then that is 
>>> going to be hard to map and would lead to confusion(i.e. All other 
>>> applications would use a different slider then oiio).  Is it possible to 
>>> make the quality slider more contextual to the compression rather then 
>>> normalizing it to always be 0-100?
>>> 
 On Tue, Sep 20, 2016 at 11:49 PM, Larry Gritz  wrote:
 maketx doesn't have a --quality command at all, primarily because we'd 
 traditionally been using either lossless TIFF or OpenEXR for textures, and 
 for neither of those did quality come into play.
 
 But recently we added support for TIFF-with-jpeg, and OpenEXR with DWAA 
 compression has since come along and looks useful, so if you think that a 
 --quality flag for maketx is helpful, we can add it.
 
 The real problem is that quality is assumed to be 0-100, with 100 meaning 
 lossless. It works well for JPEG, which is the prototypical example. But I 
 wasn't sure how to make it map to the dwa compression level without being 
 confusing (dwa compression is an open ended scale, and higher numbers mean 
 more compression).
 
 I'm perfectly happy to entertain requests to change it, if there's 
 consensus. For example, if somebody wants to propose an intuitive and 
 helpful mapping of the 0-100 scale of Quality into the appropriate 
 dwaCompressionLevel, I think that might be useful.
 
 As you've seen, you can set the compression levels for dwaa and dwab by 
 setting the "openexr:dwaCompressionLevel" attribute. It's not hooked up to 
 the "--quality" only because, ad just mentioned, it wasn't obvious how 
 that mapping should work.
 
 
 
 
 > On Sep 20, 2016, at 3:11 PM, Deke Kincaid  wrote:
 >
 > Hi Larry
 >
 > We are trying to compress EXR files in OIIO with dwaa/dwab compression 
 > but currently this does not seem to directly hooked up to the --quality 
 > flag in oiiotool.  No matter if you use --quality 10 or 100, the attr 
 > dwaCompressionLevel key never gets set and the file is exactly the same 
 > size.
 >
 > We found that we need to directly set the attr via:
 > oiiotool blah.exr --ch R,G,B --croptofull --compression dwaa --attrib 
 > dwaCompressionLevel 100.0 -o blah_dwa.exr
 >
 > Any chance we could get this attr hooked up to the quality slider?  Also 
 > it appears that maketx does not have a --quality flag either (I haven't 
 > checked iconvert).
 >
 > -deke
 >
 >
 > ___
 > Oiio-dev 

Re: [Oiio-dev] oiiotool --quality for dwaa exr ignored

[Deke Kincaid]

I like #2.

On Wed, Sep 21, 2016 at 9:36 AM, Larry Gritz  wrote:

> So in following the spirit of OIIO's core mission to allow a single
> generic API to shield users from the gory details of each individual format
> (as much as possible), I feel strongly that --quality should not magically
> change directions and scales for one format. If --quality 100 is "looks
> perfect" and lower numbers mean "smaller files, bigger artifacts" for every
> other format, it shouldn't be that for exr, 45 is perfect and larger
> numbers mean smaller files. Also, it leads to confusing errors if you set
> the "CompressionQuality" in an image metadata and then try to output it to
> multiple files of different file formats.
>
> That's why quality is basically ignored for dwaa and instead you can set
> the "openexr:dwaCompressionQuality" attribute -- it's possible to set it,
> and the name communicates clearly that you are making a peculiar
> format-specific adjustment (that will be ignored by other format writers,
> if the same output is sent to a different file).
>
> OK, but I do see that this is awkward and verbose. So I'll propose two
> alternatives, and am happy to go with whichever people want:
>
> 1. As Kevin points out, we can use something akin to Karl's mapping (I'll
> find a cubic curve that maps these smoothly?) of quality's 0-100 scale into
> settings for DWA compression quality. I don't know if that will give you a
> "smooth" response either visually or in terms of file size. If somebody
> wants to do a little research and try to map out a more perceptually or
> size-wise linear response, please volunteer.
>
> 2. Another approach is to skip --quality, and just allow the compression
> setting to be built into the compression name!  How does this look:
> --compression dwaa:45 or --compression dwaa:200. The idea is that anything
> starting with "dwaa" would turn on dwaa compression, and any optional
> trailing numbers would set the dwaaCompressionQuality.
>
> Opinions?
>
>
>
> On Wed, Sep 21, 2016 at 8:15 AM, Deke Kincaid 
> wrote:
>
>> If the constraint of —quality is that it is always 0-100, then that is
>> going to be hard to map and would lead to confusion(i.e. All other
>> applications would use a different slider then oiio).  Is it possible to
>> make the quality slider more contextual to the compression rather then
>> normalizing it to always be 0-100?
>>
>> On Tue, Sep 20, 2016 at 11:49 PM, Larry Gritz  wrote:
>>
>>> maketx doesn't have a --quality command at all, primarily because we'd
>>> traditionally been using either lossless TIFF or OpenEXR for textures, and
>>> for neither of those did quality come into play.
>>>
>>> But recently we added support for TIFF-with-jpeg, and OpenEXR with DWAA
>>> compression has since come along and looks useful, so if you think that a
>>> --quality flag for maketx is helpful, we can add it.
>>>
>>> The real problem is that quality is assumed to be 0-100, with 100
>>> meaning lossless. It works well for JPEG, which is the prototypical
>>> example. But I wasn't sure how to make it map to the dwa compression level
>>> without being confusing (dwa compression is an open ended scale, and higher
>>> numbers mean more compression).
>>>
>>> I'm perfectly happy to entertain requests to change it, if there's
>>> consensus. For example, if somebody wants to propose an intuitive and
>>> helpful mapping of the 0-100 scale of Quality into the appropriate
>>> dwaCompressionLevel, I think that might be useful.
>>>
>>> As you've seen, you can set the compression levels for dwaa and dwab by
>>> setting the "openexr:dwaCompressionLevel" attribute. It's not hooked up to
>>> the "--quality" only because, ad just mentioned, it wasn't obvious how that
>>> mapping should work.
>>>
>>>
>>>
>>>
>>> > On Sep 20, 2016, at 3:11 PM, Deke Kincaid 
>>> wrote:
>>> >
>>> > Hi Larry
>>> >
>>> > We are trying to compress EXR files in OIIO with dwaa/dwab compression
>>> but currently this does not seem to directly hooked up to the --quality
>>> flag in oiiotool.  No matter if you use --quality 10 or 100, the attr
>>> dwaCompressionLevel key never gets set and the file is exactly the same
>>> size.
>>> >
>>> > We found that we need to directly set the attr via:
>>> > oiiotool blah.exr --ch R,G,B --croptofull --compression dwaa --attrib
>>> dwaCompressionLevel 100.0 -o blah_dwa.exr
>>> >
>>> > Any chance we could get this attr hooked up to the quality slider?
>>> Also it appears that maketx does not have a --quality flag either (I
>>> haven't checked iconvert).
>>> >
>>> > -deke
>>> >
>>> >
>>> > ___
>>> > 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
>>> 

Re: [Oiio-dev] oiiotool --quality for dwaa exr ignored

[Larry Gritz]

So in following the spirit of OIIO's core mission to allow a single generic
API to shield users from the gory details of each individual format (as
much as possible), I feel strongly that --quality should not magically
change directions and scales for one format. If --quality 100 is "looks
perfect" and lower numbers mean "smaller files, bigger artifacts" for every
other format, it shouldn't be that for exr, 45 is perfect and larger
numbers mean smaller files. Also, it leads to confusing errors if you set
the "CompressionQuality" in an image metadata and then try to output it to
multiple files of different file formats.

That's why quality is basically ignored for dwaa and instead you can set
the "openexr:dwaCompressionQuality" attribute -- it's possible to set it,
and the name communicates clearly that you are making a peculiar
format-specific adjustment (that will be ignored by other format writers,
if the same output is sent to a different file).

OK, but I do see that this is awkward and verbose. So I'll propose two
alternatives, and am happy to go with whichever people want:

1. As Kevin points out, we can use something akin to Karl's mapping (I'll
find a cubic curve that maps these smoothly?) of quality's 0-100 scale into
settings for DWA compression quality. I don't know if that will give you a
"smooth" response either visually or in terms of file size. If somebody
wants to do a little research and try to map out a more perceptually or
size-wise linear response, please volunteer.

2. Another approach is to skip --quality, and just allow the compression
setting to be built into the compression name!  How does this look:
--compression dwaa:45 or --compression dwaa:200. The idea is that anything
starting with "dwaa" would turn on dwaa compression, and any optional
trailing numbers would set the dwaaCompressionQuality.

Opinions?



On Wed, Sep 21, 2016 at 8:15 AM, Deke Kincaid  wrote:

> If the constraint of —quality is that it is always 0-100, then that is
> going to be hard to map and would lead to confusion(i.e. All other
> applications would use a different slider then oiio).  Is it possible to
> make the quality slider more contextual to the compression rather then
> normalizing it to always be 0-100?
>
> On Tue, Sep 20, 2016 at 11:49 PM, Larry Gritz  wrote:
>
>> maketx doesn't have a --quality command at all, primarily because we'd
>> traditionally been using either lossless TIFF or OpenEXR for textures, and
>> for neither of those did quality come into play.
>>
>> But recently we added support for TIFF-with-jpeg, and OpenEXR with DWAA
>> compression has since come along and looks useful, so if you think that a
>> --quality flag for maketx is helpful, we can add it.
>>
>> The real problem is that quality is assumed to be 0-100, with 100 meaning
>> lossless. It works well for JPEG, which is the prototypical example. But I
>> wasn't sure how to make it map to the dwa compression level without being
>> confusing (dwa compression is an open ended scale, and higher numbers mean
>> more compression).
>>
>> I'm perfectly happy to entertain requests to change it, if there's
>> consensus. For example, if somebody wants to propose an intuitive and
>> helpful mapping of the 0-100 scale of Quality into the appropriate
>> dwaCompressionLevel, I think that might be useful.
>>
>> As you've seen, you can set the compression levels for dwaa and dwab by
>> setting the "openexr:dwaCompressionLevel" attribute. It's not hooked up to
>> the "--quality" only because, ad just mentioned, it wasn't obvious how that
>> mapping should work.
>>
>>
>>
>>
>> > On Sep 20, 2016, at 3:11 PM, Deke Kincaid 
>> wrote:
>> >
>> > Hi Larry
>> >
>> > We are trying to compress EXR files in OIIO with dwaa/dwab compression
>> but currently this does not seem to directly hooked up to the --quality
>> flag in oiiotool.  No matter if you use --quality 10 or 100, the attr
>> dwaCompressionLevel key never gets set and the file is exactly the same
>> size.
>> >
>> > We found that we need to directly set the attr via:
>> > oiiotool blah.exr --ch R,G,B --croptofull --compression dwaa --attrib
>> dwaCompressionLevel 100.0 -o blah_dwa.exr
>> >
>> > Any chance we could get this attr hooked up to the quality slider?
>> Also it appears that maketx does not have a --quality flag either (I
>> haven't checked iconvert).
>> >
>> > -deke
>> >
>> >
>> > ___
>> > 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
> 

Re: [Oiio-dev] oiiotool --quality for dwaa exr ignored

[Karl Rasche]

I think I pulled that out of my rear end one day, so don't out too much
stock in that mapping if it sounds sketchy.

On Wednesday, September 21, 2016, Kevin Wheatley 
wrote:

> Closest I've seen to a quality scale was this email from Karl
>
> https://lists.nongnu.org/archive/html/openexr-devel/2014-08/msg00049.html
>
> Kevin
> ___
> 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] oiiotool --quality for dwaa exr ignored

[Kevin Wheatley]

Closest I've seen to a quality scale was this email from Karl

https://lists.nongnu.org/archive/html/openexr-devel/2014-08/msg00049.html

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

Re: [Oiio-dev] oiiotool --quality for dwaa exr ignored

[Eric Tabellion]

You can try this instead, this worked for me in maketx:

# For high quality use this
--attrib openexr:dwaCompressionLevel 45.0

# For meduim quality use that:
--attrib openexr:dwaCompressionLevel 85.0


On Tue, Sep 20, 2016 at 3:11 PM, Deke Kincaid  wrote:

> Hi Larry
>
> We are trying to compress EXR files in OIIO with dwaa/dwab compression but
> currently this does not seem to directly hooked up to the --quality flag in
> oiiotool.  No matter if you use --quality 10 or 100, the attr
> dwaCompressionLevel key never gets set and the file is exactly the same
> size.
>
> We found that we need to directly set the attr via:
> oiiotool blah.exr --ch R,G,B --croptofull --compression dwaa --attrib
> dwaCompressionLevel 100.0 -o blah_dwa.exr
>
> Any chance we could get this attr hooked up to the quality slider?  Also
> it appears that maketx does not have a --quality flag either (I haven't
> checked iconvert).
>
> -deke
>
>
>
> ___
> Oiio-dev mailing list
> Oiio-dev@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
>


-- 
---
Eric Tabellion   e...@pdi.com
R Staff(650)-562-9146
PDI/Dreamworks
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

[Oiio-dev] oiiotool --quality for dwaa exr ignored

[Deke Kincaid]

Hi Larry

We are trying to compress EXR files in OIIO with dwaa/dwab compression but
currently this does not seem to directly hooked up to the --quality flag in
oiiotool.  No matter if you use --quality 10 or 100, the attr
dwaCompressionLevel key never gets set and the file is exactly the same
size.

We found that we need to directly set the attr via:
oiiotool blah.exr --ch R,G,B --croptofull --compression dwaa --attrib
dwaCompressionLevel 100.0 -o blah_dwa.exr

Any chance we could get this attr hooked up to the quality slider?  Also it
appears that maketx does not have a --quality flag either (I haven't
checked iconvert).

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