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] > <mailto:[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] >> <mailto:[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] <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
