Messages

How do I show a screenshot in this font system?

Not sure what you are asking.  If you are trying to show an image, there is an image button that will make the image markdown notation appear.  I think you need to post the image somewhere on the web and insert that link into the markdown notation.

I have played with it so long. I even installed Davinci Resolve on windows Adobe After Effects in my opinion is better. And even on Ubuntu it is too slow for me.

Okay.  Use what you prefer.

Somehow I researched the error message. I should install phpmyadmin.
sudo apt install phpmyadmin php-mbstring php-zip php-gd php-json php-curl

That doesn't sound right.  I don't have that installed on my system and I use both MLV App and Natron.

So nothing imports to natron.

Try importing an MP4 file or an MOV file in Natron.

By the way, the DNG file probably doesn't show any changes when exported from MLV App because DNG is a raw format -- all of the changes you made are metadata in a separate file.

TIFFs are similar in quality to DNGs.  I don't have any experience with the Windows version of MLV App.

Are you exporting TIFFs from MLV App or are you converting to TIFFs in ffmpeg?

In regards to your syntax error, your path to the TIFF file has a space in the directory name "/very beautiful/", and that space might not be parsing properly.  When you type/enter that path, an escape character such as a back slash ("\") might be required just before the space, so that it reads "/home/meerkat/Videos/very\ beautiful/M20-2351/M20-2351_000000.tif"

However, the simplest fix to that path space might be merely to rename the "/very beautiful/" directory to "/very_beautiful/".

@ChristianEOS:

I think that Natron works better with TIFF (or PNG) images.  DNGs might run a little slow on Natron.

I believe that you can export 16 bit TIFF sequences from MLVAPP.  If those images are too big, you can use ffmpeg to convert your exported MLV footage or image sequences to lower bit-depth TIFFs.

Excellent!

Amazing to see the capabilities of the EOSM, ML and MLV app!

Of course, it helps that you have a great eye!

Thanks dude,i knew this settings for manual lens. sigma 56 ef-m lens is a fully auto lens,i can take a photo when i was using sigma 17-70 ef old lens. but this time if i press and relase shutter bottum ,it seems try to pre foucus onece and do nothing.
If i uninstall ML,it will take a photo and no false.

Well, if your lens is automatic, you could be experiencing the ML EOSM "shutter bug."

You might try partially unmounting the lens.  Also, I seem to recall that certain SD cards prevent the shutter bug.

How can I release shutter buttom when I. Use a sigma 56 lens?

In the Canon menu, go to the "4th wrench" and enter the " Custom Functions" menu,  setting #7 -- "Release shutter w/o lens," and select "1:Enable."

It sounds as if an automatic setting is enabled somewhere.

If you are certain that your aperture and shutter speed settings are fully manual, then it is likely that the gain/iso is somehow changing.

Is ML "Auto ETTR" enabled?  Do you get the same behavior when ML is disabled?

In addition to footage, can you post a picture of the Canon <INFO> "Quick Control" screen?  Can you also post a photo of the ML "Modified" menu?

Yeah, that guy is really testing those presets out .

Well, instead of just discouraging someone by telling them to skip altogether trying to use an HDMI monitor with ML, @ZEEK helpfully:

• advises which ML presets are ideal for HDMI;
• shows how to adjust the ML settings within those presets to eliminate HDMI problems;
• and instructs on how to get the best framing from a monitor.

     

2) I can't use HDMI output to my phone with a capture card for 1080p mode or for 5K frtp mode. On 1080P mode, I get a black screen with no overlays. ON 5K frtp, the overlays work but I see pink distorted lines instead of the video feed.

@ZEEK posted a video just a few hours ago that includes how to get an HDMI monitor working with the EOSM.

@PaulHarwood856

Is the problem these two dots inside the red ellipse?

If not, please capture a frame and circle the problem.

@masc:  If the "Export Settings"  feature spits out all of the ffmpeg flags/variables, then it is easy enough to paste them into a command (or paste them into a file and then link the file).

Thanks for the explanation on the "Open with External Application" feature.

would it be possible to add the ability to remove jobs from the render list while rendering is underway?

when i am doing batch renders, splitting the jobs across multiple instances of mlvapp, invariably some finish earlier than others, and it would be nice to be able to have them take on clips from other instances without having the other one potentially redoing clips that were reassigned to other instances.

That's not possible in an easy way. There is currently no way to show/edit these internal data buffers, and they aren't made for this. So a huge change for a tiny feature.

What @70MM13 requests doesn't sound like a "tiny feature" -- it sounds like fundamental functionality that would be exceedingly useful to anyone doing batch renders.

If one could merely call from the command line MLV App along with a specific mlv file and recipe, the problem could likely be solved with a script (and that script function could be later incorporated into MLV App).  Such a command might read:

Code Select Expand

$  mlvapp -i your_camera_file.mlv  -s your_recipe.marxml  -o rendered_file.mp4

I don't know the function of MLV App's "Export Settings" feature, but if MLV App does everything through ffmpeg, perhaps the ffmpeg command flags/settings could be exported, and one could just run an ffmpeg batch script using those flags/settings.

Also, what is the function of "Open with External Application?"  Perhaps that feature could be utilized in this endeavor.

Good luck with your work and photography.

Likewise to you!

Your gif is well known on the web,...

I stated parenthetically that it came from the article that you linked above.  Did you catch that?

...but you could also have shown the gif showing the hinge in action from front tilt, ie see both here http://www.northlight-images.co.uk/using-lens-tilt-on-your-digital-slr/

Showing a gif depicting front tilting would be irrelevant to the point that the focus in the simulation depicts the results of moving the rear standard of a view camera -- that is why I posted the gif of the rear standard moving.

All I'm doing in TiltSim is showing the hinge, ie not the Scheimpflug line.

Yes.  I know.  I have pointed out that fact once or twice myself.

The Scheimplug method is much simpler and easier than the "hinge" to comprehend and utilize.

That is exploiting the J height from sin tilt = f/J and, of course, focus distance.

I am sure that means something, but with Scheimpflug all one really needs to consider is the tilt/swing and the actual focal length.

Ps SelectN is used because of how Desmos works. It does select the 1/3 stop aperture numbers, which are shown on the y axis ;-)

I didn't catch that, due to how the lettering is oriented and because the f-number falls near the line of the "G plane."  It might be good to run that lettering horizontally and position it cleanly in the dead space in the upper left of the graph.

Fully understand all you have said

Okay, but I am not so sure about that.

your references are sound for a large format or medium format technical camera user.

Again, the Scheimpflug Principle and the "hinge" theory apply equally to all cameras that that allow changing the orientation of the lens plane and/or film/sensor plane.

However, the Scheimpflug principle is more sound and uses tangible variables, unlike the Hinge theory, which requires one to estimate two planes that exist "in the air," some distance from their reference planes.

By the way, I think that instead of the term "technical camera" you actually mean "view camera."  On a view camera, the front and rear standards have tilt/swing/shift.  On a technical camera, only the front standard has tilt/swing/shift, much like a DSLR with a tilt/swing/shift lens/adapter.

For a TS lens on a Dslr, I'm comfortable that TiltSim is doing its job, ie as an tool to help one understand a tilt and shift lens on an Dslr

Okay, but your focus slider reflects the action of moving the rear standard of a view camera -- not focusing a tilt/shift lens on a DSLR.

Here is a GIF (from the article you linked above) that matches the results of your focus slider:


Please note how the example shows a view camera, and please observe that the "hinge line," the "parallel-to-film lens plane" and the "front focal plane" remain stationary while the rear standard of the view camera moves.

That is not how a DSLR with a tilt/swing lens works. With a DSLR, the the tilt/swing lens moves -- along with  the "hinge line," the "parallel-to-film lens plane" and the "front focal plane."

Also, it might be clearer if the "S_electN = 8" slider was labeled "aperture" and it would be helpful if that slider gave normal f-numbers.

This simulator is a tool for DSLR users, ie not for technical camera users ;-)

The Schiempflug principle (and the "hinge" principle) apply to any camera that allows changing the orientation of the lens plane and/or film/sensor plane.  So, it applies to view cameras as well as to DSLRs with tilt/swing lenses and adapters.

Also, you don't need to worry about Scheimpflug if you use the hinge, eg see here http://www.northlight-images.co.uk/using-lens-tilt-on-your-digital-slr/

Likewise, you don't need to worry about  the "hinge" notion with Scheimpflug.

Furthermore Scheimpflug is simpler and easier, because all of the "planes" in question are tangible:

• the focal plane is the sensor/film (and often marked on DSLRs);
• the lens plane is the optical center of the lens;
• and the focus plane is revealed when objects become sharp.

In contrast, the "hinge" theory is merely a more abstract variant of the Scheimpflug principle, which adds intangible, unseen "planes."

The "front focal plane" of the hinge theory exists in the air, one focal length (the infinity focal length?) from the optical center of the lens.  There is nothing physical to indicate the location of this plane some distance in the air in front of the lens, so it has to be estimated.

In addition, the hinge method adds another somewhat intangible variable with its reliance on the abstract "parallel-to-film" lens plane.  This hypothetical plane intersects the center of the lens, but it runs parallel to the film plane, regardless of how the lens is tilted/swung.  So, using the "parallel-to-film" lens plane requires yet another estimation.

The "front focal plane" estimation and the "parallel-to-film" lens estimation are both unnecessary with the simpler and solid Scheimpflug technique.

Bottom line: I wrote TiltSim to help TS-E users explore the basic principles, ahead of going into the field.

The simulation looks great!  On the other hand, it would be interesting to see such a simulation based on the Scheimpflug principle.

Regardless, the "Scheimpflug" and "hinge" methods along with simulations are no substitute for actually putting the principles to practice and getting a feel for how tilt/swings affect the plane of focus (which is actually simple and straightforward).  One doesn't normally use "math" when using tilts and swings.


Here is the pertinent passage from the travel photography blog (linked above) that might be helpful to a DSLR user who is new to tilt/swing:

"The usual focusing method using tilt is iterative, there are alternative methods based on measurements and tables but they're both slower and less accurate. The following is a simplified description of focusing using Scheimpflug with a view camera.

First, one selects two targets on the ground glass (one near and one far along the same plane). A movement is applied (usually tilt in a classic landscape) and the far target focused on. The second target is then scrutinised, using a magnifying loupe on the ground glass, and a small amount of extra movement applied. If the image gets sharper at the second target then you are moving in the right direction, if it gets less sharp then too much tilt has already been applied. Return to the first target, re-focus and repeat until both are in sharp focus.

Care must be taken to apply tilt in small amounts. Don't be tempted to go straight to sharp focus on the second target. This will mean that both targets cannot be in focus at once.

It must also be remembered that the focusing plane is a flat surface. If your subject is very three-dimensional then movements might not be the answer, it may simply be better to stop down.

The same basic focusing principles apply to T/S lenses on an SLR."

One more thing -- as I mentioned, there might be a problem with the "Focus" slider in your simulation.  It seems to be based on focusing by moving the focal plane (the sensor/film), which is not the way that DSLRs focus.  Focusing a tilt/swing lens on a tripod-mounted DSLR might give different results than what is shown in your simulation.

Interesting tool!  Excellent job!

However, I sense that you might be slightly overthinking things.  Essentially, you are illustrating the Scheimpflug principle, except that you are not really showing the lens plane nor the focal (film/sensor) plane.

Here is a simple drawing showing how those two planes relate to the focus/subject plane.  It does not include the depth of field limits. Here is the travel photography article in which the drawing appears, which includes a passage that explains the Scheimpflug principle and which succinctly describes a common practical technique own how to use tilt/swing to control the plane of focus.

To learn how the Scheimpflug principle works, it is best to just try it with your view camera or tilt/swing lens/adapter.

By the way, I am not sure if the "Focus" slider in your simulation accurately demonstrates the results of actually focusing a view camera or a tilt/swing lens.

Thanks for making the simulation!

My concern was that if someone used the script with the hard link flag, that they would inadvertently/automatically delete the camera files on the cards when the hard links were deleted.  Symbolic links tend to avoid that problem.

By the way, what is the purpose of using the directory symbolic link flag ("/D") with the mlink command?

By the way, your script appears to be creating hard links (instead of symbolic links).

When you delete those hard links, do the target files (the camera files on your card) also get deleted?

Glad to hear that it worked!

If you can successfully link a single file (not a directory) from an exfat card using this command:

Code Select Expand

mklink  C:\link\on\ntfs\drive  E:\single-file\on\exfat\card

... then you can simply batch link into a single directory on your C:\ drive all of the files (not directories) from "Card A", along with all of the files (not directories) from "Card B".

So, all of the camera files on both cards will be individually linked within a single directory on your C:\ drive.

The batch command/script to use would be something like the commands/scripts suggested in this thread.

the issue is with trying to merge the directories.

Keep in mind, the idea is to link a single file -- not a directory.  In addition, merging directories is not necessary if you can link a single file.

Also, when you got the error, was the exfat card mounted and were you the administrator when you tried to link the file?

but i did find this:  https://github.com/derbylock/MergeFS  does this look like it can be compiled?

I don't know.  I would be careful running this.

i tried again and even with links to links to links it still fails.

That sounds more complex than it needs to be.

The Windows mklink command is very simple.  If you can make it work with a single file on your exfat card, you are golden.

Just in case you haven't tried this, here is the command to test on the Windows command line (I think that you have to be root/administrator):

Code Select Expand

mklink  C:\link\on\ntfs\drive  E:\file\on\exfat\card

Of course, change the "E:" to whatever drive letter corresponds to your exfat card.

I don't use Windows, but I think that you can link from non-exfat filesystems to target files/directories in an exfat filesystem.  It seems to be working for this poster.

It's easy enough to try on a test file (with a test card).

Don't think you know what aliasing files are here?

Is "alias" a cute Apple name for what is merely a symbolic link?

@70MM13
In a single Windows folder/directory, you can create a batch of symbolic links to the files on both cards by
doing something like this.

Of course, it would be ideal if MLV App simply had built-in functionality to load files from different directories/folders.