I would like to propose an improvement in the search function (PhotoLibrary section).
Currently, you can search for e.g. lens (in mm), ISO, keyword, date, etc. Different criteria from the EXIF can be put together to refine the research.
Apparently, this works with the Boolean operator âANDâ. All the criteria stated must therefore correspond. But sometimes you would like to do a research on one criterion OR another criterion OR yet another. This would be the âORâ operator. I think it would be interesting and helpful to have that function in research as well. And, to be complete, one could also add the operator âNOTâ. So, one should have to choose from the two (or three) operators âANDâ, âORâ (âNOTâ).
In another program that I take for selection, ranking, culling, I almost only use the âORâ operator.
P.S.1 I donât know whether itâs difficult or not for programmers to integrate this into the search function.
P.S.2 I vote for the proposal
yes i vote for that. (i am nowhere near experienced user but bumped into it and itâs poking me in the eye now i know its limitation of viewing.
At this moment DPL is reading raw metadata (ctrl+i) shows that and XMP for keywords at least.
donât know if itâs reading and acting on xmp data made by FastRawViewer where WB and such can be stored.
Because there is a search function and indexing in the library; IPTC/XMP/EXIF metadata reading and viewing is core fundamental function.
lets start with fully compatible in reading and viewing like this example:
this a field where EXIF and XMP (raw-sidecar) is shown.
on a tiff or jpeg also IPTC is shown (EXIF/XMP/IPTC)
DPL reads IPTC from tiff and jpeg and write it in the exported image (passing through) but it doesnât show the info in the library browser. when hitting crtl+i
XnviewMP creates a container file like âfilename.raw_originalâ to connect IPTC data on a rawfile.
Sadly itâs not visible for DPLâs fiilmstrip. (no image to see) That seems the biggest problem: no standards in coding. and an other issue it creates a rawfile at the same size in your folder (so it doubles your needed HDDspace)
i donât like to have the raw IPTC data stored in the Database because when it is corrupted i delete and rebuild what would be destroying the build up IPTC data. It has to be a universal sidecar system like XMP is.
I hope there are some experienced users who can set up a guideline to make a universal sidecar type where XMP and IPTC data is stored to accomplish the rawfile as sidecar. ( editing inside the raw would be a change of destroying the file in a way of unable to open any more so i would like a safe sidecar system.)
Lets start by reading and showing correctly and a selection window when exporting a group of images to select which IPTC,XMP,EXIF details can be stored in the new exported file.
I had some time to burn with a cold beer in the sun.
Before dpl is in play you need some managment of raw metadata.
Exif, xmp, iptc.
Exif of rawfileâs are manageable with commandline tools, and i found a type which have a graphic shell over it.
Metadata++.
biggest issue is if you want iptc data to add on a rawfile it is mostly added in a library database.
and i think when you use DNG, which are lineair and already demosiaced which makes PRIME useless.
So we want to edit a sidecar. And according to this artical is IPTC completely suiteble to place inside a xmp.
So it would be possible to create a side car in xmp style for a rawfile so all three metadata types are present in a non database structure.
Tiffâs and jpegs can be written inside the file without a sidecar needed nor a database.
Me personal donât really need to alter exif data of a rawfile, i only want to create a xmp file where the hierarical keywords and the IPTC data can be updated, stored or created and stored.
So we donât need to use a nontransferable database nor, commandline tools to alter the rawfileâs exif block.
The only thing we need is a fully compatible xmp file(adobe 2004) , a editor of metadata and with batch functionality where the exif is read from the rawfile wile you can set up the IPTC information and then export this as sidecar next to the rawfile.
Then only what DPL needs to do is a complete readout of this XMP and a viewer if we want this to read completely. On the export side we like to have a selection window to fill in our needs to place the metadata inside the jpeg or tiff. Maybe a preset for webbased images (stripped), including a watermark.
No database needed only then to speedup searchfunctions.
Question 1
Is there a xmp generator (standalone, fairly cheap) which is using that xmp 2004 format?
XNviewMP canât place more then keywords and creates a filename.raw_original to write the IPTC. (at least i couldnât find the right functionality.)
Question 2
How much work need DxO to create a reader for this xmp file and in a later moment a editor of this xmp file?
Question 3
Same for the export module, how much work is it implementeren for this selective metadata writer?
A simple pull down window which shows you the possibilities at once. Even possible to include ranges for the numerical values and a choice if an AND or OR relation is wanted. See by example https://pixelpeeper.com/adv/
I didnât know that more criteria where possible in PL.
i think if itâs a open XMP-file you can index all you have in there and select on it.
(if itâs just text/words you can search on that. (donât know if all camerabranches are using the same layout of exif. ) and/ or itâs possible to use the lensmodule (selects the lens also) for that purpose.
which has it placed on the same place no matter the branch or type:
you can allready search on focal length as in 12-55mm
