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
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 <dekekinc...@gmail.com> 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 <l...@imageworks.com> wrote:
>> OK, my stab at this is here: https://github.com/OpenI
>> 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 <l...@imageworks.com> 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.
>>> Oiio-dev mailing list
>> Larry Gritz
>> Oiio-dev mailing list
> Oiio-dev mailing list
Oiio-dev mailing list