M: What kind of category would you call
a forest in a photograph or drawing? I'm getting stuck on the word
scenario, and that's not it. I'm looking for something to help
categorize things. Other elements in this set would be desert, city,
waterfall, that kind of thing. I just can't think of the right word.
G: TL;DR: The word
you’re looking for is most likely “landscape.”
Best fit
- Landscape → standard umbrella term for scenes like
forest, desert, city, waterfall
- Works in photography, art, and general categorization
- Implies the environment rather than an event or
situation
Close alternatives
(slightly different nuance)
Setting
- More narrative-oriented (where something takes place)
- Works, but leans storytelling rather than classification
Environment
- More technical/scientific tone
- Good for systems, less common for art labeling
Scene
- Very general
- Can feel a bit vague or moment-specific
Terrain / Biome
- More scientific/geographic
- “Biome” especially if you're grouping by ecology (forest, desert,
tundra)
Quick distinction
(why “scenario” felt wrong)
- Scenario = implies events, actions, or conditions
unfolding
- You’re describing static visual categories, so it
doesn’t land right
Bottom line
If you want something that feels natural, widely understood, and
flexible:
→ “Landscape” is the cleanest answer.
M: Can you come up with anything better?
Because it's supposed to be a categorization kind of thing for an image
set. So landscape is a little bit particular. Like, if it's just the
shot of a forest, or if it's a scene of like a picnic in a forest, both
of them should go in this category as a forest. Like I said, landscape
implies more of a type of image rather than giving what I'm looking for
in terms of setting.
G: TL;DR: The
cleanest word for what you want is “setting”.
If you want something more system-like: “environment”
or “locale.”
Why “setting”
actually fits better than it sounds
- It ignores what’s happening (picnic vs empty forest)
- It focuses purely on where it is
- Works cleanly across:
- forest
- desert
- city
- waterfall
This is exactly how games, film, and literature classify scenes when
they don’t care about action.
Strong alternatives
(depending on tone)
1.
Environment (most neutral/systematic)
- Feels like a database field
- Clean, non-artsy
- Good for tagging systems
- Slightly clinical, but very stable
2.
Locale (tight, underused, very precise)
- Means “place where something occurs”
- Doesn’t imply action
- Slightly more formal, but very clean categorically
3.
Backdrop (if you want visual emphasis)
- Implies “what’s behind the subject”
- Works even if something is happening in front
What to avoid (and why)
- Landscape → implies a style/type of
shot
- Scene → mixes action + place
- Scenario → implies events unfolding (wrong
axis)
Bottom line
If you want one word that behaves correctly across all
cases:
→ Setting (most intuitive)
→ Environment (most system-friendly)
→ Locale (most precise, slightly formal)
“Locale” is probably the closest thing to what you were reaching for
but couldn’t quite name.
M: Okay, go online and tell me how the
program XnView treats categories versus how it treats the permanent tags
that it puts into an image. Like, is there a difference, and if so, can
I put the categories into the image as an EXIF tag, or what?
G: TL;DR:
- In XnView, Categories ≠ metadata —
they’re primarily a database system inside XnView.
- What actually gets embedded into files is keywords
(IPTC/XMP).
- You can make categories write into the file, but only by
converting them into keywords, not as a separate
“category” field.
1.
The core distinction (this is the part you were actually asking)
Categories (XnView internal)
- Stored in XnView’s catalog/database, not inherently
in the image
- Used for:
- filtering
- browsing
- hierarchical organization
- Think: your tagging system UI
“Categories… manage a database (filter, search…)”
citeturn0search1
Also explicitly:
“Categories are separate and distinct from keywords, with categories
stored in a separate database.” citeturn0search20
- Stored in:
- IPTC keywords
- XMP subject / hierarchical subject
- These are:
- portable
- readable by other programs
- This is what Lightroom, Photoshop, etc. actually see
- NOT metadata
- Just a quick marking/flagging system
“In XnViewMP ‘tag’ is a marking feature, no metadata corresponding.”
citeturn0search1
2. Can categories be
written into the image?
Yes — but only as keywords
You cannot store “categories” as their own thing in EXIF/IPTC in any
meaningful modern way.
What XnView does instead:
- Converts categories → keywords
- Writes them into:
- XMP (
dc:subject, hierarchical keywords)
- IPTC keywords
“Categories can easily write… XMP subject… and hierarchical subject.”
citeturn0search3
Enable “Export catalog’s categories” to write categories as IPTC or
XMP keywords citeturn0search8
3. Important
nuance (this is where people get burned)
Even if you enable export:
- Categories still exist separately in the
database
- The file only gets keywords derived from them
That means:
- You can lose sync
- Removing a category doesn’t always clean the keyword cleanly
- Other programs will only ever see keywords, not
your category structure
4. EXIF specifically
(your direct question)
Short answer: No, not really
- EXIF is mostly technical camera data
- Not intended for structured tagging like this
“Almost all exif fields are technical informations… written by
cameras” citeturn0search0
So:
- Don’t use EXIF for categorization
- Use XMP/IPTC keywords
5. Practical
translation to your use case
What you want (“forest / desert / city” as a classification
layer):
Correct way in XnView:
- Create categories like:
- Environment → Forest
- Environment → Desert
- Then:
- Enable export → writes them as keywords
What ends up in the file:
What stays only in XnView:
- The hierarchy (unless you use XMP hierarchical
keywords)
6. Clean mental model
- Categories = your working system (inside
XnView)
- Keywords = what survives outside XnView
Bottom line
- Yes, there is a real difference:
- Categories = internal database structure
- Keywords = actual metadata
- You cannot store categories directly in EXIF/IPTC as
categories
- You can export them → keywords
(XMP/IPTC)
- If portability matters, treat keywords as the “real”
data and categories as a convenience layer
That distinction is the whole game with XnView.
M: Okay, then not EXIF. I was using the
wrong term. Which is the better choice if I've got a hierarchical setup?
Like I'm trying to create a situation where the viewer and the database
that you're talking about has, for example, a category called food, with
a subcategory of fast food. And I want both of those included in terms
of the long-term tagging. And then, let's say, what was one example?
Structures. I have a few different structures that I've used as tags,
but I don't actually want structure in there as a tag, just the
subcategories of bridge or landmark or whatever. What would be the
appropriate tagging system to use and enable and whatever?
G: TL;DR:
Use XMP hierarchical keywords as your real
tagging system.
- Turn on export categories → XMP hierarchical
keywords
- Control whether parent terms (like “Structure”) are included
- Treat categories as your editor, XMP keywords as the final
truth
The system
that actually fits what you described
✅ XMP Hierarchical
Keywords
This is the only option that cleanly supports:
- Parent/child relationships
- Selective inclusion (parent optional, child required)
- Cross-program compatibility (Lightroom, etc.)
Example (your case):
Food|Fast Food → stored as hierarchy
Structure|Bridge → you can choose to export only
“Bridge”
You want two behaviors:
1. Preserve hierarchy where
useful
- Food → Fast Food
- Nature → Forest
2. Suppress
“organizational-only” parents
- Structure → Bridge
- Structure → Landmark
So your setup should:
- Enable:
- Export categories → XMP hierarchical keywords
- Then control:
- Whether to also export flat keywords (important
distinction below)
The
critical toggle (this is where your use case lives or dies)
You’ll run into two export behaviors:
Option A — Export
full hierarchy as keywords
Good when:
- Parent is meaningful (Food)
Option B — Export leaf-only
keywords
Good when:
- Parent is just organizational scaffolding
What you actually want
(hybrid behavior)
XnView doesn’t perfectly “think” like this by default, so the clean
approach is:
- Build hierarchy in categories
- Then:
- Use hierarchical XMP for structure
- Control flat keyword export to include only leaf
nodes
Clean mental model
(important)
You’re really building two layers:
Layer 1 — Internal logic
(Categories)
- Full hierarchy
- Includes helper nodes like “Structure”
Layer 2 — External truth
(XMP keywords)
- What survives outside XnView
- Should be:
- meaningful
- minimal
- portable
Practical recommendation (no
fluff)
If you want this to behave long-term:
Use:
- XMP hierarchical keywords (ON)
- Flat keyword export (LIMITED / leaf-focused)
Avoid:
- EXIF entirely
- IPTC-only (older, flatter, less flexible)
Subtle but important insight
You are describing two different types of parent
nodes:
1. Semantic parents (keep)
- Food → Fast Food
- These belong in metadata
2. Organizational parents
(discard)
- Structure → Bridge
- These are just for your workflow
Most systems don’t distinguish this automatically — you have to.
Bottom line
- Use XMP hierarchical keywords as your storage
format
- Use categories only as a management layer
- Export carefully so:
- meaningful parents stay
- scaffolding parents disappear
That gives you a system that’s both structured and portable
without clutter.