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
