Can you help me with three questions about how raw images are handled.
I have a directory containing Canon CR2 images and have auto management on. Am I correct that Photostructure just copies the CR2 images into the new library. Assuming that is the case, then is there a jpg image also created somewhere for the photostructure viewer (and if so where), or does it render on the fly?
Is there a list of formats that photostructure supports.
If there is an image in my original library that is not supported does auto file management just ignore it. Iām hoping to collect everything in a single place and am a little concerned that unrecognized files will be ālostā when creating the new library, but not sure whether thereās a solution to this.
Rendering is all done at import time to make browsing fast.
V0.9.1 uses dcraw, which supports many raw formats.
v1.0 (which I hope to have alpha releases ready in a week or two) switched to libraw, which supports many more recent raw formats. The only raw format that Iām aware of that it doesnāt support yet is cr3, which they say will be ready soon.
Currently, yes, but thinking about it more, it seems like it would be better to import it if possible: most raw images have fairly large embedded JPEG images that I can use for full-screen. Iāll think about this some more: thanks for bringing this to my attention!
const librawSupportedMimeTypes = new Set([
// TODO: add hasselblad, leaf, leica, phase one
// See https://www.dechifro.org/dcraw/#cameras
"image/x-adobe-dng",
"image/x-canon-cr2",
// "image/x-canon-cr3", // TODO: these aren't supported by libraw yet
"image/x-canon-crw",
"image/x-epson-erf",
"image/x-fuji-raf", // < both are found in the wild
"image/x-fujifilm-raf", // < both are found in the wild
"image/x-kodak-dcr",
"image/x-kodak-k25",
"image/x-kodak-kdc",
"image/x-minolta-mrw",
"image/x-nikon-nef",
"image/x-nikon-nrw",
"image/x-olympus-orf",
"image/x-panasonic-raw",
"image/x-panasonic-rw2",
"image/x-pentax-pef",
"image/x-samsung-srw",
"image/x-sigma-x3f",
"image/x-sony-arw",
"image/x-sony-sr2",
"image/x-sony-srf"
])
Thanks. Thinking along these lines, there are other image-related formats that Iād also like to have imported (just copied, not converted) so they are all saved in once place. For example, I have an Insta360 camera that generates INSV files for 360 panoramic info in addition to the DNG files. Would it make sense to include these to the import list (or even better, an option to add files of a custom type to the config file)?
There are a bunch of filters that are applied to determine if a file is relevant for importing. One of those is dimensions. If ExifTool can extract dimensions from the .insv, then event cleared that hurdle.
The code that copies files into the library needs to be able to extract a ācapture atā time in order to know what subdirectory it should copy it into. Do these files have always that metadata? (You can use the info tool to see what PhotoStructure thinks).
Can you send me a DM or email with an example file set (the insv and dng)?
Ideally the files would have matching metadata to merge them into the same asset, and then a different variant (something PhotoStructure knows how to render, like the dng) can be picked as the āprimaryā or āshownā asset file.
Is it ok to copy a file into your library even if it canāt be rendered by PhotoStructure? (This is what youāre asking, right?)
Thanks. Iāve sent you an email with some example files.
Just copying would be great - I donāt expect Photostructure to render the file. However, a bonus would be to display the file name and/or capture time in the āimage squareā so at least the user would know it exists?
Iāve just rebuilt PhotoStructureās internal list of supported file extensions using the latest version of ExifTool, and the .insp extension was recently added
With this change, the next version of PhotoStructure will properly import these files.
(Theyāll be rendered as distorted panoramas, though. )
I would add a vote/suggestion that just about any file appear as a blank file icon - maybe this is a bad idea, but sometimes you have a random PDF or something in a directory and if they donāt appear at all, they kind of get lost.
Not sure if there is a better solution to that kind of thing.
One of my very first PhotoStructure beta users said āOh, this would be perfect for organizing my recipes on PDF!āā¦ (sometimes feedback knocks you back a bit!) Conceptually, as long as PhotoStructure can render a file in the browser, it could be imported into the library, but I think there are many general file-sharing apps already available, and it would certainly pull the product in different directions. Iāll think about this more.
I was into testing with you back in 2018/2019, but life pulled me away a while.
Been looping back and catching up with things a little. Youāve come a long ways
I agree that Iām not sure itās a ābest fitāā¦ but there is a lot of overlap - my struggle is how to handle files that are associated with my pictures.
Just as an example off the top of my head - if I have a vacation, I will have a collection of pictures, but along with that I may have an itinerary I saved (which kind of makes part of the ātrip historyā), some PDF brochures of places we visited, whatever. How best to juggle those together. Right now I usually have my āarchiveā of trip stuff and my photos over in āphoto landā.
Where do these collide? Not sure.
But please concentrate on v1 and v2 and v3 and just let these thoughts niggle in the back of your mind for when they are appropriate
Stumbled across PhotoStructure a couple of days ago, and have to say it looks very promising!
Just a bit disappointed to learn that it doesnāt support .cr3 - at least yet - but I hope that will change soon.
Also, would like to add my support for .pdfās - another, more professional usecase is that model and property release forms may need to follow the photos into storage (the photos may be commercially unusable without these legal forms).
The Fujifilm X-Pro2 with compressed raws is my preferred camera / file format when just having fun with a camera, so this was going to be my next question. Iām very happy to see that fujifilm compressed raws is included in that release!
I am running alpha 2 and it looks like libraw is still generating pinkish images from my sony RX100 VI.
Can you let me know what the command line format is so I can run some tests in the docker container. Iām assuming you are using the dcraw_emu command?
If you were using an earlier version, I didnāt make PhotoStructure alpha.2 automatically rebuild previews (as it seemed that only a few people saw this issue). If you click āresync this assetā while viewing any pinked images, itāll force-rebuild the previews.
Iāll get you that command as soon as Iām at my desk. If you DM or email me an example raw image, thatād be great (nothing with anything private, please!)
)
