Sort of… Xmp is a standard, and there are both standard tags and room for custom, per application tags. Quite a few applications respect the standard tags.
Like I said, you’re lucky if you can read standard information like date and tags (but even that is more luck than it really works). The edits are never interchangeable (since every program does different calculations).
Core i5-8250u, limited at +/- 15 watts, 16gb of RAM, default Lenovo SSD, Windows 10:
https://filedn.eu/lIyLo2maGUwuy7XtCSQMTxY/filmulator-rotate.mp4
(I captured the window, not the screen, so you won’t see file-pickers or past the 1-minute mark where I’m opening the saved tiff. Didn’t feel the need to retake the video :)).
Rotating is visually almost instant (it starts recalculating the 1:1 version, and you need to wait for it to rotate again, but it’s nowhere near 20 seconds).
I can’t see how an older I7 makes that much of a difference. And I wonder if video-driver support can have an impact in rotating?? Maybe something else going on.
Hello @jorismak
Rotating is visually almost instant
Thanks a lot for testing my image
At work, I have got a laptop with Windows 10 where I can easily install Filmulator.
I am going to check whether this hardware fares better with Filmulator:
CPU Intel i7-10710U
RAM 16 Gb
SSD 512 Gb etc etc
The older i7 is dual core, while your newer i5 is quad-core.
Also, Filmulator is fairly RAM-hungry, directly related to the resolution of the image you’re working with.
It seems that on Linux, it takes 7.5 gigs of memory for a 45-megapixel Z7 with 1500 pixel previews, so memory capacity is likely your issue. It’s swapping out to your hard drive/SSD.
However, you can reduce the “Preview render resolution” in the settings. Setting it to 1000 pixels reduces the peak RAM usage on Z7 images to 6.2 gigabytes, which might make the difference for you. Additionally it’ll just make all the sliders more responsive on your older CPU.
Edit: I’m fixing the “Reduce memory usage” option which didn’t work properly with “Render small preview first”. It doesn’t help as much as it used to now that preloading is a thing, but… it’s dreadfully slow to switch images without preloading, especially on slow laptops with insufficient ram…
Edit two: maybe I’ll have it disable preloading at the same time…
Edit three: with preloading disabled, it now uses about 5 gigabytes of ram for a 60 megapixel image, though it’s dreadfully slow to respond to slider inputs after the first one.
2021-01-03: v0.11.0rc5
Fixed the “reduce memory usage” option by having it disable preloading.
It’s still dreadfully slow though.
Hello @CarVac
Just tried the new version (rc5) on my old notebook (Windows 10).
Now it performs much better than before.
I can rotate my RAW images without any major lag.
Thanks a lot!
2021-01-06: v0.11.0rc6
In light of variants of DNGs produced by various applications that are unsupported by LibRaw having shown up on the forum, I improved the checks Filmulator makes when importing to properly reject files that cannot be processed.
2021-01-10: v0.11.0rc7
The Organize view now starts on the current date.
When on the Organize tab, the left and right arrow keys now changes the selected day. Holding shift while you use the left and right arrow keys lets you select a range of dates, much like with the mouse.
When you right-click on an image, the image rating shortcuts now apply to the right-clicked image and not the image currently selected in the Filmulate tab.
2021-01-26: v0.11.0rc3 (yes it skipped a few
- Attempt to deal with a bug on NFS network shares
- Attempt to fix importing from UNC file paths on Windows
- When you save an image, a popup appears to indicate that it worked
- After updating Lensfun, the user is now prompted to restart.
2021-01-28: v0.11.0rc5
@quiteinterested I’ve fixed TIFF export ISO sensitivity metadata.
Fantastic. Yes it’s working now. Thanks!
I’ve just noticed that if the exposure time is sufficiently fast, then the metadata for the exported TIFF file lists the exposure time as 0.0 seconds (I think the value is not being recorded).
The cut-off happens somewhere between 1/60 and 1/150 (i.e. TIFFs with an exposure time of longer than 1/60 carry the correct metadata).
It happens with both DNG and RW2 raw files.
More mysteries to investigate…
Haha! It was ever thus…
What application are you reading it with?
Filmulator is writing a floating point value and it’s being read fine by exiv2, but the tag is supposed to be rational and LibTiff can’t write them from what I can tell.
I’m going to try to make it use Exiv2 again, which darktable apparently does successfully, but the last time I did that it was crashing Photoshop. So I need someone with Photoshop to test that it works once I make a change.
I’m using Rawtherapee and a Windows-only application called FastStone Image Viewer. Unfortunately I don’t have access to Photoshop so I’m of no help in that regard.
If switching to darktable will solve the issue I’m happy to do that; I have no particular attachment to Rawtherapee after having become familiar with your software, and it is only for high ISO files requiring noise reduction that I use TIFF export.
Update 2021-01-31: v0.11.1rc6
- TIFFs now have the correct format shutter speed metadata; I do need people with Photoshop to test that the TIFF output doesn’t cause crashes.
- A backslash in a string broke one translation; I fixed that.
- When you use a raw file as an argument to Filmulator, it imports it and now also directly loads it and goes to the Filmulate tab.
Update 2021-02-04: v0.11.1rc7
By request on Reddit I made it possible to override the “do not import in place from a directory containing DCIM because it can be a memory card” error.
Update 2021-02-12: v0.11.1rc8
@Luemmel may be happy to hear that I’ve implemented a white balance picker for Filmulator.
When you pick the white balance, it stores the settings per-camera for the editing session so you can easily apply it to other images. You can also store manually-set white balance values.