DigUp Mac Search Guide: Local Files, Multimodal Indexes and Privacy

DigUp Mac search is useful to evaluate when you remember what a file contains but not its name. A photograph, a PDF passage and a moment in a recording are different retrieval targets. Putting them behind one search box is helpful only if the result opens at the evidence you intended to find.

This guide proposes a small local archive test, explains folder scope and highlights Chinese search cases worth checking. It relies on the maintainer's documentation and does not claim a hands-on installation or privacy audit.

Check the current Mac requirements

The canonical DigUp repository describes an Apple Silicon application requiring macOS 14 or later. It uses EmbeddingGemma 2 for multimodal search and combines semantic retrieval with exact-word matching. The documented installation options are a release DMG and a Homebrew cask. DigUp repository.

Start from that repository's release link rather than a similarly named fork. Record the app version and model version when evaluating it. A change to retrieval behavior can come from the application, the embedding model or the index, so a version number for only one component is incomplete.

The project's Mac requirements do not establish current Windows or Linux availability. If your team uses mixed operating systems, confirm the actual downloadable release before planning a shared workflow around it.

Index a small folder with known answers

Create a test folder containing files you are permitted to process. A useful starter set includes a product photograph, a screenshot with a distinctive error, a short PDF with a known clause and a recording with one identifiable topic. Note the expected file and location before indexing.

Use descriptions that resemble how you forget files. For the photograph, ask for an object or scene. For the PDF, ask for the subject of the clause. For the screenshot, try the exact error string. Then deliberately ask for something absent from the folder and inspect whether unrelated results seem too convincing.

Do not start with your whole Downloads folder. A bounded set lets you distinguish an indexing failure from a poor query. If a file is absent, check whether it was within the selected scope, whether it was locally available and whether the relevant reading stage completed.

Maintain a simple retrieval sheet:

Measure search quality before speed. An immediate result that opens the wrong page is less useful than a slightly slower result with the right passage.

Treat audio and video results as evidence locations

The README describes audio processing through overlapping windows and video retrieval through sampled frames and soundtrack analysis. This means you should inspect the returned moment, not assume the system exhaustively understood every frame or word. Documented file readers.

For an audio test, place the topic in a short passage between unrelated sections. Search with a paraphrase, then listen around the returned location. For video, choose a scene with a visible object that appears briefly and compare it with a sustained appearance. These tests expose whether your archive's useful moments are represented well enough for retrieval.

Check the handoff to the viewing application too. A search can locate the correct interval while playback starts somewhere else because of permissions or player behavior. Record those as delivery failures rather than rewriting the query endlessly.

Evaluate Chinese exact text separately

The maintainer explicitly notes limits for exact-word matching in languages without spaces, including Chinese, and separate language coverage for screenshot OCR. That is a reason to test Chinese archive queries directly rather than assuming a multilingual embedding claim covers every retrieval method. DigUp FAQ.

Use a pair of queries for each Chinese document: one semantic description and one literal identifier. Include mixed Chinese and English names, invoice numbers and strings containing punctuation. Verify which route produces the correct file and whether the returned passage contains the exact identifier.

If a query fails, try a narrower phrase and inspect the source text extraction. An image of a page, a searchable PDF and a plain text note can reach the index through different readers. Preserve that distinction in your test sheet so you can identify an OCR limitation instead of blaming the embedding model.

Keep code search and privacy scope explicit

DigUp documents code search as an opt-in feature with selected folders and a separate index, using the code: query prefix. Evaluate it on a small repository with a known function before adding your full development workspace. Code search instructions.

For privacy, the README states that indexed content stays on the Mac and describes model downloads and update checks. Treat that as the maintainer's stated design, not an independent guarantee from this article. Confirm the installed build, settings and network behavior if your organization requires evidence of local processing. Privacy statement.

Folder selection is still your responsibility. Exclusions are useful, but do not use them as the only protection for sensitive material. Start with a deliberately chosen archive, understand where its index lives and include that index in your device access and backup planning.

Worked archive: locating evidence from a product project

Imagine a small team preparing a product release. Its local archive contains a packaging photograph, a PDF specification, a recorded design discussion and a screen capture of an error. Create a synthetic version of this archive using your own material so the test can be shared without customer or company data.

Give each file a neutral name rather than putting the answer in the filename. Write several questions based on the contents: find the photograph with a damaged corner, locate the specification paragraph about operating temperature and find the moment when a speaker discusses a packaging change. Record the correct file and page or interval before indexing.

Run a semantic description and a literal query for each item. The semantic question tests retrieval by meaning; the literal question tests identifiers or exact text. Keep both results even when only one succeeds. This shows which retrieval route suits a particular kind of evidence.

For the specification, add a second document with an older requirement. A search returning both may be useful, but the user still needs version information to choose the current one. Preserve dates and document labels in the archive and inspect how they appear in the opened result.

For the recording, ask a question that describes a topic rather than repeating the speaker's exact words. Listen at the returned interval and note how much extra playback is needed to reach the relevant statement. A result near the correct discussion is different from one opening directly at its useful beginning.

Finally, ask for an item that is not in the archive. The system may still rank the nearest files. Teach reviewers to distinguish relevance from mere availability: a search result is a candidate, not proof that the requested evidence exists.

Make indexing coverage visible before evaluating relevance

Track the files you expect to be searchable and their completion state. A poor result can mean the index lacks the file, the reader missed a page or the query ranked an indexed item too low. Those are different problems. Do not improve query wording until you know the evidence entered the index.

Test one file of each important type before importing a large folder. Open the source normally on the Mac and confirm it is present locally. A cloud placeholder or damaged media file may look like part of the archive while its content is unavailable to a local reader.

Use a long PDF as a separate coverage case. Place known passages near its beginning and later pages. Search both after the indexing interface reports progress, and record when they become available. This prevents a partially processed document from being judged as a completed retrieval failure.

For video, include both visual and spoken evidence. A visible object without matching speech tests a different representation from a topic mentioned in the soundtrack. Keep separate expected locations for those cases rather than assuming one result validates both modalities.

When a file changes, repeat its known query after the update has been processed. Then remove a disposable test file and check how the result behaves. Current-file behavior matters for a working archive; an old result that opens a missing path can confuse users even if its original embedding was correct.

Use a query ladder for difficult files

Begin with the natural description a user remembers. If it fails, try a narrower description containing the central object, topic or action. Then try a distinctive literal string from the source. Save all attempts rather than keeping only the successful query; the difference reveals how much knowledge a user needs to recover the file.

For a photograph, compare a broad scene description with a detail-specific one. For a document, compare a topic with an identifier. For an audio clip, compare a paraphrase with a short spoken phrase. This ladder is a proposed evaluation method, not a guarantee that each query style is supported equally.

Avoid rewriting a query around details you learned only after inspecting the correct result and then calling the original search successful. That makes a demo look better while hiding the user's actual difficulty. Preserve the first attempt as the realistic retrieval case.

For Chinese material, include text with spaces around English identifiers and text written entirely in Chinese. Also try a bilingual paraphrase. Review semantic results and literal-string results separately because the documented tokenization and OCR boundaries can affect them differently.

If exact business identifiers are essential, keep a conventional search route available. Semantic retrieval can help discover a document while exact text confirms that it contains the intended invoice, model number or error. Combining those checks in a review workflow is more dependable than treating a high-ranked candidate as an exact match.

Measure local resource use during the archive's real lifecycle

Separate first-time indexing from ordinary search. Measure time and system responsiveness while the initial folder is processed, then repeat queries once that work completes. A long import can be acceptable for a rarely changing archive but inconvenient for a folder that receives large media files throughout the day.

Add a small batch of new files and observe when their known queries begin returning results. Then modify an existing document and repeat the update check. These measurements describe your workload; do not substitute the maintainer's example timings as results for your own archive.

Record the index's storage footprint together with source file count and types. A thousand short notes and a thousand long recordings are not equivalent datasets. If the index grows unexpectedly, inspect coverage and selected folders before making a broad claim about application efficiency.

Test search while other ordinary work is running. The useful question is whether the Mac remains usable for your workflow, not whether a query can be fast on an otherwise idle machine. Keep hardware and power state in the evaluation record so later comparisons are meaningful.

For battery use, decide whether large imports should wait until the device is connected to power. Use the application's documented controls where available and verify the behavior. Avoid promising that local processing is free of battery or heat costs merely because it avoids a hosted inference endpoint.

Treat the index as a local information asset

The index can reveal what files exist and what their contents concern. Include it in your access review, even if the original files remain unchanged and no indexed content is uploaded according to the project's design. A local search database is still information about the archive.

Check which user account owns the application data and how that folder enters backups or device migration. If several people share a Mac, evaluate access under the actual account setup. Locality alone does not define who can search or copy the resulting index.

Document removal before a pilot. Use the project's current uninstall instructions and verify what remains on a disposable test setup. Removing an application icon and removing its model, index and settings are separate operations. Do not perform destructive cleanup on a real archive just to demonstrate the process.

Keep the code index scope narrow when enabling that optional feature. Test a known function query and confirm the opened editor location. If the repository moves or changes branches, review the index update behavior before relying on old results in a development task.

The final adoption decision should state which archive types passed, which queries require literal confirmation and which coverage issues remain. That gives users a practical search tool with understood boundaries instead of an unsupported promise that every file can be found from any description.

Conclusion

Adopt DigUp after it finds your own known files and opens the right pages or moments. Expand the indexed scope gradually, keeping Chinese exact text and code retrieval as separate checks. A compact test archive is a practical way to review later app and model updates.

FAQ

Does DigUp replace every Spotlight search?

It adds semantic and multimodal retrieval. Keep exact filename and metadata search available while evaluating which route works for each task.

Is Chinese search equally reliable across file types?

Do not assume that. Test semantic descriptions, literal identifiers and screenshot text separately; the README documents exact-word and OCR limits.

Does local processing remove the need to manage access?

No. The chosen folders, local index and device access still matter. Review the installed application's scope and the maintainer's privacy statement.