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