I second the vote for #2

On Sep 21, 2016, at 9:59 AM, Deke Kincaid <dekekinc...@gmail.com> wrote:

> I like #2. 
> 
>> On Wed, Sep 21, 2016 at 9:36 AM, Larry Gritz <l...@imageworks.com> 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 <dekekinc...@gmail.com> 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 <l...@larrygritz.com> 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 <dekekinc...@gmail.com> 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
>>> 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

Reply via email to