Open darbyjohnston opened 5 years ago
Hi, thanks for the offer of help! There isn't a plan yet so I guess it would be good to start making one. :)
I'm still a beginner at Blender so I guess the first question is, what support does Blender currently have for DJV? I've seen this documentation but haven't tried it:
https://docs.blender.org/api/blender_python_api_2_70_4/bpy.types.UserPreferencesFilePaths.html
@fsiddi might also have some thoughts on Blender/DJV integration.
That setting is just to set what player gets opened when clicking Render -> View Animation to review the rendered frames, so not much of an integration, just a dropdown to choose between Djv, RV, MPlayer and others
Nice, that sounds like a good start; what other features do you think would be good to add? If that setting can supply command-line arguments it would be nice to pass along additional information like FPS and color settings, there's an issue for adding those here: https://github.com/darbyjohnston/DJV/issues/139
The file related to opening an external player in Blender is located here.
One thing that may need attention is packaging. I’ve only used the deb package, so I don’t know about others, but right now with the deb install you can’t call djv directly from the command line since the binary isn’t in the PATH. I think that according to the FHS, it would need to go into /usr/bin/. That would also be useful for general usage.
Also, it might be good to make a soft link from /usr/bin/djv_view as well, since Blender and possibly other programs and scripts used that as the binary name. That way, they would be compatible with DJV 1.x and 2.x, depending on the user’s install.
Since you do stuff in djv.sh
, the file at /usr/bin/djv could actually be a link to that:
$ ls -l /usr/bin/djv*
... /usr/bin/djv -> /usr/local/DJV2/bin/djv.sh
... /usr/bin/djv_view -> /usr/local/DJV2/bin/djv.sh
You’d need to modify djv.sh so it reads something like:
appname=`basename $(realpath $0) | sed s,\.sh$,,`
dirname=$(dirname $(realpath `which djv`))
# ...
(This may be fixed by commit bdb06aefed9699ab3d8c6585d7664750a84c3050, I couldn’t compile and test.)
About command line arguments, as you can see at line 140, the internal Blender player supports frame_start
and frame_end
arguments, which may be useful to preview only the currently set frame range, in addition to the FPS.
Hi, I'll look into creating the /usr/bin symlink with the DEB and RPM packages, though I'm a bit reluctant to also link the new DJV to the old name since that would prevent having both installed. Hopefully the new DJV will reach feature parity soon with the older version but for now it can still be useful to have both installed.
(This may be fixed by commit bdb06ae, I couldn’t compile and test.)
Did you run into a problem with compiling? If so please let me know and I'll try and resolve it.
Good suggestion on the frame start/end arguments, I added them to https://github.com/darbyjohnston/DJV/issues/139.
Hi, I'll look into creating the /usr/bin symlink with the DEB and RPM packages
Thanks!
I'm a bit reluctant to also link the new DJV to the old name
Looking at the code in Blender, it needs to be updated anyway, especially on macOS. And it’s probably not too complex to update scripts users may have.
Did you run into a problem with compiling? If so please let me know and I'll try and resolve it.
Thank you, I opened a new issue #200.
I just checked in a change that adds the "/usr/bin/djv" symlink install for both DEB and RPM packages, it seems to work OK on my Ubuntu and CentOS machines. If you want to try it out there are directions for how to create packages here: https://darbyjohnston.github.io/DJV/build_linux.html#Packaging
Thanks, adding the "realpath" to the wrapper script was necessary to get it to work.
Cool, the packaging worked as expected on Ubuntu, and I got a working djv binary in the path!
Now I could send a patch to Blender to update the binary name and remove the existing command line option, but maybe this should wait until these are stable?
Great, thanks for testing it out!
I'm not familiar with the Blender development process, about how long do patches normally take? I was hoping to get a new release of DJV out within a week or two.
I don’t contribute to Blender’s core, only to the Python add-ons, so I can’t say for sure. The development cycle is quite complicated, and right now it’s in a "bugfixes only" phase, so such a patch would go into the second version from now. In my experience, reviews are quite fast, and this doesn’t look like a complex issue. But there is no rush anyway.
I’m modifying the Blender code to include the new command line options. Do you think they are still bound to change, or should I propose the changes for inclusion into Blender? Maybe when version 2.0.6 is out?
Hi, I think they are good to go for version 2.0.6, I've checked in fixes for the other issues you found with them. If I can get the rest of the bugs resolved I would like to make the 2.0.6 release this week.
Cool! I’ll keep you updated when I make that patch.
Hi, I'm still working on a few last bugs and will try and make the release next week... Also I realized we probably need one more command-line option to get the "-frame" and "-in_out" options working properly with your patch. By default DJV uses timecode where instead you probably want to use frames; this can be changed in the application settings but it would probably be more robust to set it on the command-line, so I was thinking of adding a "-time_units" option. So the command-line would look something like this:
> djv render.####.exr -time_units frames -in_out 200 300 -frame 250
Does that seem reasonable?
That’s a great idea! Changing the setting is always the first thing I do since I don’t use timecodes for single image sequences, but a command line option would be more practical. I have a patch ready, but I’ll wait until the next version of DJV is out before submitting it, so that Blender’s devs may test it without having to compile DJV.
If you’d like to test the Blender integration, you can move the attached script to blender-2.82-<platform>/2.82/scripts/startup/bl_operators/screen_play_rendered_anim.py
, then in the user preferences’ File Paths tab, set the Animation Player to Djv. Once you have rendered a sequence, you can hit CTRL + F11 to open it in DJV.
By the way, I took a look at the number of downloads for version 1.3.0 on Sourceforge, and saw that it was still downloaded about one-third as much as the latest version. This makes me think it would be good to support both versions in Blender for the time being, especially since you took care not to give the same name to the executables. Do you agree?
So I ran into something while adding the "-time_units" command-line option, what to do about the translations? Does the user enter the translated string or the key?
Translated string:
> djv -time_units Images
Key:
> djv -time_units time_units_frames
I don't think the translated string works, since your script would then have the locale hard-coded in it. Using the key seems OK but maybe not the most user-friendly, and also doesn't match what the UI shows in the settings.
Other alternatives could be to limit the command-line to English, or use the index of the enumeration instead of the name:
Index:
> djv -time_units 1
Where 0 = timecode and 1 = frames. Also maybe not the most user-friendly... Any thoughts?
If you have time to add support for the 1.3 version I think that would be useful, the new version still has some missing features.
Other alternatives could be to limit the command-line to English
I’d go with this last option. As you said, translating the command line options is impractical, but this should be remedied by documentation. The best option if you want to do that would be to display the help translated in the current locale, or in the saved preferences language. But I think most who would use command line options are scripters and thus at least a bit familiar with English anyway, so this is not urgent. Anyway, the option could be:
> djv -time_units [frames|timecode]
If you have time to add support for the 1.3 version I think that would be useful, the new version still has some missing features.
I made another version of the patch already but since it adds a new value to a C enum, Blender must be rebuilt for it to work so I didn’t send it here. We’ll see what the Blender developers think, as well.
Hi, sorry for the delay! I tried your script on Windows with the latest Blender and it worked great, nice job!
I got sidetracked by a different project but will get back to DJV this week to finish the command-line option and last couple of bugs.
OK, I just checked-in a change to add the "-time_units" command-line option; here is the usage:
-time_units
Set the time units. Options: "Timecode", "Frames". Current value: "Frames".
I tried it out with your script and it seemed to work OK.
I also made it so that the command-line language is always English; it took a bit more work than I expected, hopefully I didn't break anything else in the process. :)
It works! I modified the Blender script, set DJV’s preferences to Timecode, run the sequence from Blender, and DJV plays it in frames. :D
Great, thanks for testing it out!
The new DJV series is now selectable from Blender! Campbell, the core developer who edited and merged the patch, reckons the two DJV versions need not be added simultaneously in the way I did it, but that a version selection could be added if needed. I’ll let you decide if it’s worth it asking for it, keeping in mind that the next version is scheduled for the end of August.
Hi, that's great news! Thanks for following up with this. I'm fine with just using the newer version, maybe it will have feature parity by August. :)
My pleasure. I’ve been busy working on other stuff but I didn’t forget. :) By the way, any news from Weblate about hosting the project’s translation?
I never heard back from them, but I just sent a follow up email to their support to see if there are any updates.
Good news, I got email from Weblate that they will be setting up space for DJV soon; apparently they have had a huge queue of requests to work through.
@darbyjohnston Sorry to necro this task a bit but there's currently an issue where Blender's DJV launch setting does not work if used on Windows.
I think this is due to the Windows installer not placing "C:\Program Files\DJV2\bin" into the PATH. Attempts to launch the executable with just the name "djv" isn't going to work. If the user manually adds it to the PATH, then things work fine, but some (most?) don't know how to do that[1]. Would it be possible for the Windows installer to modify the PATH variable itself?
HI @jessey-git, thanks for reporting the issue. I did a quick search and it looks like I can use the CMake variable "CPACK_NSIS_MODIFY_PATH" to enable this:
Modify PATH toggle. If this is set to ON, then an extra page will appear in the installer that will allow the user to choose whether the program directory should be added to the system PATH variable.
https://cmake.org/cmake/help/latest/cpack_gen/nsis.html
I created a separate issue to add this for the next version: https://github.com/darbyjohnston/DJV/issues/449
What exactly is the plan here? Maybe I can help out :)