Forum Replies Created
-
Posts
-
I have fixes for this bug. If you are interested in beta testing it, please email support@gentlemencoders.com. Thanks.
Hi,
I’m sorry you are encountering a problem with export. I spent a while trying to reproduce this; I believe I finally know what is happening. There are two different bugs.
1) I store the list of images in the order you select them, but iOS reorders them (an iOS call I make apparently does not respect the order I pass in)
2) The “original file name” setting is not working reliably.I do not have a workaround at this time for either problem. The fixes are not trivial; they will take some time to make.
I’m sorry I don’t have a better answer right now.
Hi,
I believe that the “swipe turning into full-screen” issue is the device occasionally registering a tap vs. a swipe (which is determining in part by distance the finger moves when it is touching the screen, as well as how long). There may be a way to ignore taps in this situation, but I would have to look into it (there isn’t a way directly with iOS – I’d have to implement some kind of heuristic).
There is not a current way to view the real RAW version without entering edit. There are two reasons for that:
1) often, the RAW is not present on the device and has to be downloaded. Downloading the RAW would greatly affect the interaction experience when moving through the library. It could be a preference, of course. Right now there is already an issue where the app needs to download the full-size preview – this would be worse with RAWs.2) RAWs require a lot of memory, so it puts a lot of pressure on the system. Memory pressure can lead to crashes (when an app uses too much memory, iOS terminates the app). This is an issue some customers experience currently even with the current system, so I’m sure it would be worse.
If RAW loading occurs automatically, then as people swipe through the library, the app will have to start and stop RAW loads. Unfortunately, there isn’t a way to do that in iOS – it’s possible to cancel a download, but not a decode. As a result, memory will spike as there are multiple images being decoded at once, which will certainly crash the app. The app can wait a few seconds before loading the RAW, but a) that is annoying in its own way and b) everyone swipes at a different rate. The result is that some people swipe at just the right rate to have a terrible experience. This happened a lot with Aperture 1.0.
Both issues could probably be overcome, but it’s quite a bit of work. Something I’ll think about for the future, but not something I can do right now.
Hi Erik,
I have thought a little bit about soft-proofing but not much. The basic idea is pretty simple – it’s a matter of changing the output color profile used when rendering images for display or output (but there are some gotchas that have to accounted for or the results will be incorrect). Embedding a profile is also straightforward.
It’s not on my near-term list, but it is something that is on the list for a future release. There are some very important (and large) features that are taking priority.
V3 will support Photos libraries (similar to the way RAW Power for iOS works). The existing file browser system will continue to exist with new features, etc. No worries there.
RAW Power uses Google Analytics to measure the usage of some features (for example, how much people use the Extension vs. the standalone app vs. the Lightroom plugin). There isn’t any personal information tracked. It also does not use any advertising IDs.
Hi Erik,
Inline:
Use a fixed number of digits for exporting with custom name and sequence, potentially as a parameter with a default value of 3 digits that the user can modify.
I’ll put that on the list for a future release.
Export in the (chronological) order in which the images are being displayed in Raw Power.
This is a bug – it should respect the sort order. I’ll put that on the bug list.
When exporting files, set the file creation date to the original image capture date.
I checked Aperture, Photos, and Lightroom. None of them set the file creation date to the original image capture date (all preserve the EXIF capture date, as does RAW Power). In general, I’m hesitant to mess with file creation dates. If the other two issues are resolved, I believe your situation would be okay, since the images would come in the right order.
And, yes, it can make quite a mess, especially if the sidecars are also used for metadata like ratings or flags (because many more images have such things applied to them).
Storing the sidecar next to the file would help in many cases, but it doesn’t always work – the app may not be able to write to the directory, for example. So, at the very least, there needs to be a fallback that uses the sandbox. But in the fallback case, because two original files can have the same name (from different folders), the app would need to give each sandbox file some kind of unique specifier. As a simplification, I ended up storing all the sidecars in the sandbox. The “hex data” is the unique specifier – because of how it’s constructed, the app can connect the sidecar to the original even if the files move.
BTW: even if the sidecars were next to the originals, you would still have a problem. The connection between sidecar and original would be broken once you renamed the originals [unless, of course, you renamed the original and sidecar together].
Hi Erik,
Sorry you ran into a problem there. RAW Power stores adjustments in sidecar files located in its “sandbox” directory. Because the sidecars are not in the same directory as the originals, RAW Power uses the file name + some metadata to associate the sidecar with the original.
So, if you edit, then rename the original, the association is lost.
One solution to this situation is to (carefully) rename the sidecar file. This is how to do it:
1) Finder: Go > Go to Folder
2) Paste the following (no quotes) and hit return:
~/Library/Containers/com.gentlemencoders.RAWPower/Data/Documents3) you will find a bunch of files; some are jpgs, others are the sidecars.
The jpg is the “full size” jpeg preview made by the app after editing.4) The first part of the name is what you want to change:
(e.g., “ _DSF3894” in the below name)
“_DSF3894-(DNG)-09AB0010364E7A110FE92FB019E45BE9”I suggest duplicating the sidecar file before renaming it, so you can easily restore it if the rename goes awry.
I suggest also renaming the full size jpeg the same way.I hope this helps.
—Nik
Hi, I don’t know why the map is not displayed. Here are some possibilities:
1) Apple cannot resolve the coordinates to a place
2) something about maps itself (maybe a privacy setting).If you want to email a picture to me to look at, I can see if it has to do with the file. To do that, email support@gentlemencoders.com. I recommend mailing a zip file rather than sending the image directly through the mail program.
Thanks.
—NikDNG and RAW are not the same thing. DNG is a file format created by Adobe to hold image data. It can hold both RAW and non-RAW data.
Apple uses DNG to hold RAW data for iPhones, as do some other camera manufacturers. Most, however, have their own proprietary RAW image format.
“RAW” can means two things: a) sensor data that has been minimally processed by the camera and b) a quasi file format. There is no file format called “RAW” — a RAW file is simply a file that contains RAW data. Each RAW decoder has code to read the various manufacturer file formats to extract the RAW sensor data + metadata.
Boost works on the entire image, providing both brightening and color enhancement. Brilliance in Photos has an overall brightening effect, but it’s not color-oriented.
Boost actually is used in Apple Photos for RAWs, but there is no slider exposed for it. Though Boost is at the top of the user interface, it is one of the last filters that is applied, both in Photos and RAW Power.
