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
