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] > <mailto:[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] >> <mailto:[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] <mailto:[email protected]> >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> > > -- > Larry Gritz > [email protected] <mailto:[email protected]> > > > > _______________________________________________ > Oiio-dev mailing list > [email protected] <mailto:[email protected]> > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > <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
