Golly, that looks a lot more complicated than I was going to suggest. maketx / make_texture_impl end up storing the maketx command line as the "Software" metadata
For update mode, if the destination exists, I was merely going to quickly open the file as input, read its "Software" metadata, and compare it to the present one (excluding the version number, before the colon), and if they DON'T match exactly, then assume the texture has to be re-made, even if the input and output dates are identical. I grant that your method is more "exact", inasmuch as it wouldn't produce a false positive if you remake the texture with literally different but feature-equivalent arguments (for example, the same arguments but in a different order), whereas my approach would needlessly remake the texture in that case. But my hunch is that this is a rare case -- the command lines of a true intended repeat will be identical, and that remaking the texture for the odd corner case where this assumption is too stringent is a small price to pay for such simple implementation (maybe 10 lines versus ~400). I'll give it a stab tomorrow. > On Dec 4, 2015, at 7:37 PM, Thiago Ize <[email protected]> wrote: > > I had some free time this evening so I coded up the following quick patch (on > our OIIO 1.5). It needs some massage to put it in the OIIO coding format > (indentation is off, etc...) and I duplicated some functions which I bet with > some refactoring could be much improved. It also doesn't handle checking for > user-specified attributes (I have no idea what those are). For my purposes, > this is good enough, but I suspect you'll want to clean it up if you end up > committing it into OIIO. > > In argparse.cpp, there is a memory leak if a user called parse(string), and > then parse(xargc, xargv). I don't know what your rules are on c++11 for > OIIO 1.5, but this code would be way simpler if you could use > std::unique_ptr. If you can use an alternative such as from boost, that > would work too. > > Here's how it looks in action: > > 8:13% maketx ~/Desktop/IMG_1067.JPG --checknan --tile 32 128 -o "out of\ > file.tx" -u > maketx: no update required for "out of\ file.tx" > 8:13% maketx ~/Desktop/IMG_1067.JPG --checknan --tile 32 32 -o "out of\ > file.tx" -u > 8:13% maketx ~/Desktop/IMG_1067.JPG --checknan -o "out of\ file.tx" -u > 8:13% maketx ~/Desktop/IMG_1067.JPG --checknan -o "out file.tx" -u > 8:13% maketx ~/Desktop/IMG_1067.JPG --checknan -o "out file.tx" -u > maketx: no update required for "out file.tx" > 8:14% maketx ~/Desktop/IMG_1067.JPG -o "out file.tx" -u > 8:14% maketx ~/Desktop/IMG_1067.JPG -o "out file.tx" -u > maketx: no update required for "out file.tx" > 8:14% maketx ~/Desktop/IMG_1067.JPG -u > 8:14% maketx ~/Desktop/IMG_1067.JPG -u > maketx: no update required for "/Users/thiago/Desktop/IMG_1067.tx" > 8:14% maketx -u ~/Desktop/IMG_1067.JPG > maketx: no update required for "/Users/thiago/Desktop/IMG_1067.tx" > 8:14% maketx -u ~/Desktop/IMG_1067.JPG -v > maketx: no update required for "/Users/thiago/Desktop/IMG_1067.tx" > > Thiago > > On Tue, Dec 1, 2015 at 9:09 PM, Thiago Ize <[email protected] > <mailto:[email protected]>> wrote: > deal :) > > On Tue, Dec 1, 2015 at 6:06 PM, Larry Gritz <[email protected] > <mailto:[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] >> <mailto:[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] <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> > > > > <maketx-u.diff>_______________________________________________ > 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]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
