deal :) On Tue, Dec 1, 2015 at 6:06 PM, Larry Gritz <[email protected]> wrote:
> I'm busy but it also sounds pretty simple. Mainly I didn't want us both to > do it. > > How about this: whichever one of us gets around to starting it first, send > the other an email so they know not to redundantly do it. > > > > On Dec 1, 2015, at 4:28 PM, Thiago Ize <[email protected]> wrote: > > I haven't gotten around yet to fixing this. Of course I won't complain if > you (or someone else) wants to tackle this. If you're busy, just let me > know and I'll give it a shot. > > On Tue, Dec 1, 2015 at 5:17 PM, Larry Gritz <[email protected]> wrote: > >> I think this totally makes sense. The dumb -u behavior is probably just >> an artifact of having predated our current use of the metadata and the >> growing richness of command-line options. >> >> So are you proposing to do it, or are you requesting that I do it? >> >> >> >> On Dec 1, 2015, at 4:11 PM, Thiago Ize <[email protected]> wrote: >> >> That's exactly the solution I was imagining. >> >> I think it's less surprising to rebuild the .tx file if the arguments are >> different. Right now users might be confused why their changes aren't >> taking effect. After this, if users are trying to create the same file it >> will likely early exit and if they are trying something new, it will >> rebuild. The wrong case (what surprises users) shifts from the image >> incorrectly still being outdated to the correct image being used through >> extra redundant work. So trade incorrect image for correct but slower >> images. >> >> On Tue, Dec 1, 2015 at 5:01 PM, Larry Gritz <[email protected]> wrote: >> >>> The original meaning of -u is "skip the work if the source image is >>> older than the existing texture output." Dumb and simple! Also, easy to >>> understand and not prone to people wondering why it did or didn't succeed. >>> But yes, I totally see your point. >>> >>> You are proposing to try to make it much smarter: "skip the work if you >>> are reasonably certain that you'll get the same image as last time." >>> >>> I think this should be possible. The command line arguments are stored >>> in the metadata of the texture file! So I suppose it could parse that and >>> compare to the present command line arguments. >>> >>> The question is, will this produce a more subtle behavior that >>> inadvertently causes people to be frequently surprised or not understand >>> what it's doing? >>> >>> >>> On Dec 1, 2015, at 3:07 PM, Thiago Ize <[email protected]> wrote: >>> >>> I think my question is best explained through an example: >>> >>> $ maketx --colorconvert linear sRGB foo.png -o foo.tx >>> ... creates a foo.tx >>> $ maketx -colorconvert linear linear foo.png -o foo.tx -u >>> ... does nothing since timestamps are the same >>> $ maketx -colorconvert linear linear foo.png -o foo.tx -u >>> ... does nothing since timestamps are the same >>> $ maketx foo.png -o foo.tx -u >>> ... does nothing since timestamps are the same >>> >>> Wouldn't it be better if instead of just checking timestamps, it also >>> checked if the arguments used to create the .tx file are different? Then >>> you'd get something like: >>> >>> $ maketx --colorconvert linear sRGB foo.png -o foo.tx >>> ... creates a foo.tx >>> $ maketx -colorconvert linear linear foo.png -o foo.tx -u >>> ... updates foo.tx >>> $ maketx -colorconvert linear linear foo.png -o foo.tx -u >>> ... does nothing since the resulting file would be the same >>> $ maketx foo.png -o foo.tx -u >>> ... updates file since arguments are different (let's not try to think >>> too hard about whether linear to linear would have done the same thing or >>> not). >>> $ maketx foo.png -o foo.tx -u >>> ... does nothing since the resulting file would be the same >>> $ maketx foo.png -u >>> ... ideally would do nothing, but I wouldn't be too upset if it updated. >>> $ maketx -u foo.png >>> ... do nothing. We should ignore ordering differences when applicable >>> >>> I can imagine trying to handle all cases is rather complicated (such as >>> different arguments that produce the same image), but if we can at least >>> get the easy cases, and if in doubt, always do an update, I imagine that >>> would handle 99% of the use cases and would only have the drawback that >>> very rarely maketx would end up doing redundant work, which is annoying but >>> at least results in a correct file. >>> >>> Thiago >>> _______________________________________________ >>> Oiio-dev mailing list >>> [email protected] >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>> >>> >>> -- >>> Larry Gritz >>> [email protected] >>> >>> >>> >>> _______________________________________________ >>> Oiio-dev mailing list >>> [email protected] >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>> >>> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> >> >> -- >> Larry Gritz >> [email protected] >> >> >> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> >> > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > > -- > Larry Gritz > [email protected] > > > > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > >
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
