Jump to content
You must now use your email address to sign in [click for more info] ×

Affinity, we need clarification: are you or aren’t you working on a DAM?


Recommended Posts

On 3/11/2019 at 10:23 AM, v_kyr said:

Download the Nikon NEF codec and NRW codec for Windows from the Nikon software download website, install those and afterwards IrfanView is still a fast responder for those RAW formats. - Beside that there are a bunch of photo managers etc. just a short list of some common is shown for example here. However the Net is full of those.

Unfortunately ... due to the "proprietary" nature of the AFFINITY file format, NONE of the free applications you've mentioned, nor many of the available "pay-for-play" applications available, and many of which are very capable, DO NOT read the Affinity file format natively and are therefore not really suitable choices.

SERIF really needs to step up to the plate and get their version of some form of DAM software published already. It is their lack of such that is forcing me to return to PHOTOSHOP 6 and LIGHTROOM 5.5. 

Sure, they're a bit dated, but the quality of image enhancement is still high-quality and my need for the ability to manage a large library of images demands my attention in a format that I can rely on, and work with on a daily basis, without adding to an already busy workload.

If you want the base to stay with you SERIF, get on the ball and get the software released already. The original $40.00 it cost to switch to AFFINITY is not enough to not abandon it in favour of having a solution that just works, end to end.

SERIF ... WE ARE TIRED OF WAITING!

Link to comment
Share on other sites

On 3/8/2019 at 5:59 AM, AiDon said:

Why don't you look at Adobe Bridge that is free ... 

... because NONE of them have the ability to read the AFFINITY proprietary file format. Affinity has no intention of releasing that format information either. BRIDGE is an OK image manager, AND it can read PS layer format without any issues. Most, if not all other DAM softwares DO NOT read the Affinity file format, and as a result the end-user sees the AFFINITY LOGO in place of their image after processing in AFPHOTO. BRIDGE DOES NOT read AFFINITY file format. It returns a large pink Affinity Logo instead of the image that was just processed.

NOT OK.

SERIF, either release the information and make it available so that AFPHOTO processed images can be read by other softwares (DAM particularly) or say goodbye.

Link to comment
Share on other sites

Proprietary formats is a good way to fail as a business.  There are a ton of programs that can read and write Photoshop (.PSD) files.  If Affinity is serious about being the new player on the block, it MUST publish an API that at least allows software developers to read  the format:

Level 1.  Read the file's meta-data, and the preview image.

Level 2.  Write new metadata.

Level 3.  Extract a version of the edited file.

***

I bought affinity on a sale with the promise of a DAM.  I haven't used it, because the DAM isn't there yet.

Level's 1 and  at least partial support for level 2 (Write *some* metadata info -- modify existing metadata)

I participated heavily with Luminar's forum too.  I'd learned from my lessons, however and didn't buy the software.   They too are going down the "Next year..." path.

 

Link to comment
Share on other sites

I've said this before, but it bears repeating:  

 

Introduction

Currently using Apple Aperture. Need a replacement.

I've been thinking a lot about photo management.

I'm starting to avoid the word 'DAM' as it increasingly refers to industrial sized software costing tens or hundreds of thousands of dollars. So let's look at what I mean by a photo manager:

  • Browser -- look at a bunch of pictures
  • Tagger -- add metadata either singly or in batches.
  • Searcher -- use complex searches to narrow down what I look at.
  • Version tracker -- ability to keep track of derived images.

That's the TL;DR version.

Next level of detail:

Browser Pix initially come in in bunches, and as such they go somewhere in some folder structure on your computer. Many people will use some combination of Year/Month/ and string to describe event. Often remembering that the shot took place on your trip to Italy, or that it was the Smith & Brown wedding is sufficient.

Tagger But what do you do when you are looking for the closeup of a butterfly. It was an incidental pic on some holiday, but which one. Now metadata comes into play. If all your holiday shots are tagged 'Holiday' and your program can search existing metadata, your problem is solved. Search for holiday and focal distance less than 5 feet. You still may have a bunch to wade through. If, in addition to some general keywords for the batch you add a few per image you have a big win. E.g. "Butterfly"

Tagging is hard. You want to tag it with multiple things. E.g:

  • Describe the scene.
  • Identify the location. GPS is fine, but "Lock Ness, Scotland" or Kensington market, Toronto, Ontario, Canada is easier to visualize.
  • ID the people in the scene. Classify them more generally. (Woman with child; Young boy...)
  • Describe the technical aspects -- close up, high/low key, lighting
  • One or more classes of description about the scene -- weather, mood.
  • Usage: Have you sold exclusive rights for this image? Exclusive for 18 months for a calendar?

These are facets. I prefer to go through a set of images several times, concentrating on one of these at a time. Sometimes a facet is irrelevant. Weather makes no sense for an interior shot. If you do facets, you need a way to search for images that don't have an entry for facet X. You also need a way to mark a facet as irrelevant.

Crudely you can implement these with constructs like WEA:Cloudy but then you still have to be able to search for images that don't have WEA:* as a keyword. And you have to decide on what to do where it's not relevant. WEA:N/A

Having some kind of support for actual facets would be a big win.

Hierarchical keywords are important, and it's partner, controlled vocabulary. You really want to be able to avoid having entries for Smith, John and be unable to distinguish between the one from Hoboken, NY and the one from East Horsebiscuit, SD. You also want to avoid Rachmaninov, Sergie and Rachmaninoff, Sergie. So controlled vocabulary is your friend. At the very least it should require you to take an extra step to add a new word.

The database needs to be bulk editable. E.g. When you started out you had a category, "People" and everyone was under people. Well, after a while that was getting cumbersome. So many friends. So you want to introduce some subcategories People -> High School Friends; people -> industry aquaintences... You want to be able to move someone from one category to another, and have those changes propagate to the images involved.

Searcher No point in tagging if you can't search the data. Two programs I trialed, Mylio and Photoshop Supreme, had no provision to search exif data -- where the stuff like time of day, and focal length, and camera model is kept. One program allows you to search for only one tag at a time. I can search for Holiday. Or I can search for butterfly. But I can't search for shots that have both "Holiday" and "butterfly" Ideally you want full boolean search support with 'and,' 'or', & 'not', parentheses for grouping, and wild cards for partial matches.

Version tracker A photograph for a professional may have a long history. You often have a shot, then export it in some altered form (cropped, resized, sharpened, colour adjusted, watermarked) Nice to be able to find the original 5 years from now. One recommended practice I ran into had the following:

  • Master image was Raw.
  • Archive version was digital negative.
  • Processing version was 16 bit tiff or PSD
  • Delivered version was tiff or jpeg.

This requires a minimum of 4 versions. Add to that:

  • Watermarked versions.
  • Reduced resolution versions for web pages.
  • Colour matched versions for specific printing environments.
  • Cropped versions for mobile web pages.

So that's the base case. Implementations differ, and they refine this somewhat.

Online resources

Impulse Adventure (site: https://www.impulseadventure.com/photo/) Unfortunately out of date. But still several good articles.

Controlled Vocabulary (site: https://www.controlledvocabulary.com/ )

Also has a good forum/mailing list.


Requirements:

The four functions above describe what it should do. Here are some more details about how it should do it.

Server requirements

I can see implementing this in one of two ways: Either as a stand alone program or as a local web server. The latter has the advantage that it would scale for family or small photo business.

Cloud services are slow when you are talking about 10-12 Mbyte files. My network connect takes several seconds per MByte. Cloud services for metadata have to be well optimized -- you really don't want to issue 3000 keyword change requests individually when you change the spelling of a keyword. So:

  • Not cloud based.
  • Runs on Mac or on local apache web server.

Keyword handling

  • Fast keywording. Aperture allows drag and drop from a list, multiple sets of hotkeys for words used frequently, copy paste of keywords from one photo to another, and keywords organized in folders. It also allows search for a keyword, and a list matching what you typed so far appears. Other programs that have good keywording include IMatch and Photomechanic. One of the key aspects of this is to have multiple ways to do things. I like aperture's multiple preset buttons -- combine with facets.

    A history of keywords might help: A pane with the last N keywords in it. Chances are that the next word I use will be one of the last 20 I use about 80% of the time.

  • Full access to standard metadata: EXIF, ITPC, subject to limits of the file format.

  • Controlled vocabulary. I want an extra step to add a new keyword to my list of keywords. This helps with the the Sommer Vacashun problem.
  • Hierarchial vocabulary. E.g. Separate entries for Birds -> raptors -> falcon and Planes -> fighters -> falcon. Parents are stored with keywords. Moving a keyword in the master list, or changing spelling, corrects all usage in photos. This can be done as a background task.
  • Parent items are automatically entered as keywords. (With the correct database linkage, this comes free as a side effect of the point above.
  • Synonyms -- I can define "Picea glauca" as a synonmym for "White Spruce" entering one, enters the other.
  • Facets: For a set of pictures I want to be able to define a set of facets or categories for collections or folders. Facets would be things like: Weather; Who; Where; Ecosystem; Season; Lighting Not all collections would have all facets, but a collection having a facet would nag me to put it in. A facet would have a negation for not applicable (Weather isn't applicable inside a house; Who isn't applicable in a landscape shot.) Facets allow me to go through a collection in multiple passes and get the missing keywords.

Searching

  • Complex searches: Find all shots between 2012 and 2015 shot in December or January, shot with my Nikon D70, with keyword "snow" rating of 3 or better shot after 3pm in the day. (Yes, I do use searches like that)
  • Saved Searches. These are the equivalent of smart albums in Aperture. As new pix meet the standards they would be shown.

Version Tracking

  • Version tracking If a lower resolution, cropped, photoshopped, composited or a black and white image is produced from a master, the system should show that it's a derived image, and allow access to the master. A master should be able to list derived images. Derived images are not linear but form a multi-branched tree.
  • If my camera produces JPEG and Raw versions, I want the JPEG to be shown as being derived from the Raw version.
  • Metadata applied to a master should propagate down to derived images.
  • Some form of exception handling for this: e.g. -keyword to prevent a people identifier being applied to an image where that person was cropped out.
  • Ability to track through external editing programs. E.g. If I edit a program in photoshop, it will mark the PSD file as being derived, restore as much of the metadata as the PSD format allows. If Photoshop is used to create a jpeg image, that too is tracked.

Data robustness

  • All metadata is indexed.
  • Metadata is also written to sidecar files.
  • Where possible metadata is written to the image file itself. (optional -- can stress automated backup systems)
  • Through file system watching, name changes and directory reorganization are caught. Relevant sidecars are also renamed, and the database updated with new file location/name. Sidecar contents include the name of their master file.
  • Should be possible to rebuild entire database from images + sidecars. Should be able to restore all file metadata from database. This requires a lot of under-the-hood time stamps to determine which has priority.
  • All database actions should be logged and journaled, so they are reversible.
  • Reasonable speed with catalogs of more than 100,000 images.
  • Support for previews of all common image formats and most raw formats.
  • Previews and thumbnails are treated as versions of the master. They inherit metadata.

Nice to have:

  • Simple non-destructive editing -- crop, brightness, contrast.
  • Rating system
  • Smart albums
  • Drag and drop functionality with other mac apps.

Metadata Storage

There are three places metadata can be stored:

  • In the image.
  • In a database.
  • In a separate file for each image (sidecar file) Typically these files have the same name as the primary file, but a different suffix.

If at least some cataloging information is written to the image, then you can reconnect a file to your database. In principle this can be a single unique ID.

This saves you from:

  • You moved or renamed an image file. If you can write more info into the file -- keywords, captions -- then you are saved from:

  • Your database is corrupted. You upgraded your computer and your database program doesn't work there.

Sidecar files allow you to recover all your metadata if your database crashes.

Downsides of storing data in the image

Writing to the original files can corrupt the file. Most RAW formats are well understood enough now to at least identify and replace strings of metadata with the same length string. If you tell your camera to put the copyright string

Copyright 2018 J. Random Shutterbug Image XXXX-XXXX-XXXX-XXXX-XXXX-XXXX  

Then as long as the DAM keeps that string the same length you are golden.

Keeping all metadata (or as much as you can) in the original images makes for very slow access. Your program has to read at least the first few blocks of every image. Depending on the file structure, adding too much data may require rewriting the entire file. Any program that moves the boundaries of data sub blocks better be well tested.

Writing data back is time consuming.

Some file formats don't have any metadata capability.

Some file formats (Photoshop PSD) are noted for mangling metadata.

A glitch during the write process can corrupt the image file. The alternative, writing a new file, then replacing the old file requires that the entire file be both read and written, rather than just a chunk of it. This has serious performance issues.

Downsides of Databases

Databases are fast, but they are blobby, and you are writing into the middle of blobs of data. If the implementation of the database is solid, there isn't much to worry about. But hard disks have errors, and a single error can make a database partially or fully unusable. Good database design has redundancy built in so that you can repair/rebuild.

Databases are frequently proprietary. Data may be compressed for speed. Getting your data out may be tricky. (Problem for people using Apple Aperture)

Databases frequently are optimized in different ways. In general robustness is gained at the cost of performance and complexity. One compromise is to write all changes first to a transaction file (fast...) and then a background process does the database update in the background. This slows down access some: Have to check both the main database and the transaction file, but unless the transaction file gets to be bigger than memory, this shouldn't be noticeable.

Downsides of Sidecars

You have to read a zillion files at startup.

If you do a batch change (Add the keyword "Italy" to all 3000 of your summer holiday trip shots) the catalog program has open, modify and write back 3000 files.

If you rename a file, and don't rename the sidecar file too, your meta data is no longer connected to your image.

Best practice

Opinion only here: Sorry.

  • You want a unique asset tag that resides in the image. This can be an actual tag like the copyright one mentioned above, or it can be a derived tag from information in the image. This could be the EXIF time stamp (Not unique -- multiple shots per second, multiple cameras.) If your program reads makernotes, the best one is Camera model + Camera serial number + timestamp + hundredths of a second.

  • You want a database for speed. It, of course has the unique ID

  • You want sidecars for rebuilding your database, and for data portability. They have the unique ID.

If the database crashes, it can be rebuild from the sidecars.

If a sidecar is corrupted, it can be rebuilt from the database.

If an image is renamed the ID can be used to reconnect it to the sidecar, and to fix the database.

To make this work, you have to use a lot of timestamps. If the sidecar is more recent than the latest time stamp in the database record, then the sidecar is the authoritative record.

You also have to have internal checks on data integrity. The record for an image (sidecar or database) needs a checksum to verify that that data isn't corrupt.

Given the relatively fragile nature of raw files, best practice is a system that only writes zero or once to the Raw file. This is why the exif time stamp + hundredths, copyright work well. You can include the camera model and serial number in the copyright so that now the copyright message is unique to the camera. At this point you have the ability to create, and recreate a unique ID for each image. If the DAM has the ability to modify the file, you can create this ID once. This saves some time if you ever have to rebuild the database.

Having as much of the metadata in the file as possible means taht it travels with the file. This is a win, but comes with the risk of potential corruption. Possibly the best strategy is to leave the original intact, and for clients who need raw data, either add metadata to a copy, or to a derived full data equivalent (e.g. DNG)

Sidecars don't need to be updated in real time. The slick way to do this would be that whenever the database makes a change to a record:

  • Make a new record that duplicates the old record in the database.

  • Make the change in the new record.

  • New record is flagged, "not written to sidecar"
  • Old record is marked "obsolete"
  • Another thread writes the sidecar files out, writing out the new one, then deleting the old one (or renaming the new one to the old one's name).
  • Periodically you run a cleanup on the database removing obsolete records older than X days. This gives you the ability to rollback changes.

This is not complete: It doesn't address the issue of non-destructive edits. Many programs now allow the creation of multiple images from the same master file, and do not create a new bitmap, but rather a file with a series of instructions for how to make the image from the master. AFAIK all such methods are proprietary. This results in a quandary as the apps that do a good job of tracking metadata may not be able to deal with the non-destructive edits. This can be critical if you crop a person out of an image, crop to emphasis a different aspect, and receive a different caption, etc.

The workaround is that you always write out a new bitmap image from a serious edit. Ideally you have a script that looks for new NDEs and writes out an image based on this, copying the metadata from the master and at some point bringing it up for review for mods to the metadata.

Robustness against external programs.

I like having an underlying file structure organization. I like the idea that if I produce a bunch of cropped, watermarked, lower resolution, etcetera versions of an image that my catalog will track that too.

But if the underlying file structure is exposed to Explorer or Finder, then you have the risk of a file being renamed or moved, and the database is no longer in sync with your file system.

To budnip answers of the form "This is impossible" here's how to "Finder-proof" your image database.

  • When an image is edited, a file system watcher notes that the file was opened. The file goes onto the 'watch' list. (the program fswatcher does this on mac. I use it to update my web page when my local copy has been edited.)

  • When a new file appears in a monitored directory tree, it's noted.

  • When a file is closed, this is also noted. If there has been a new file created it is checked for metadata. If the new file's metadata has a match for an existing file, then existing file metadata is used to repopulate missing data in the file. (Photoshop is notorious for not respecting all metadata.)

  • Database is updated with the new file being marked as derivative of the original file.

  • optionally a suffix may be added to the new file's image number, showing whether it derives directly from the original or from another derivative.

To make this work, the two components are a unique id that can be calcuated from the master, and a file system monitor program that catches create, move, change, and rename events.

Notes on current state of the art:

  • Nothing I've found supports version tracking, especially through an external program. Lightroom and Aperture both support a type of versions -- different edits on same master, but at least Aperture doesn't copy metadata to a new version. Aperture supports Stacks -- a group of related pictures.
  • Lightroom: Doesn't support PNG, very clunky interface, slow on large catalogs;
  • Mylio home version doesn't support hierarchical keywords; doesn't index exif information, does not allow or syntax for searches,
  • Photomechanic is fast for keywording and culling, but has very limited search capability.
  • IMatch. Possible contender, Requires MS windows box.
  • Photo Supreme: Erratic quirks. Crashes. One man shop. Can't search Exif in useful way.
  • Fotostation: AFAIK no underlying database. Has to read metadata from images/sidecar files on startup. Slow after 10K images. (They have server based software too that is big bucks.)
  • Luminar: A DAM has been promised Real Soon Now, but no demos, storyboards or feature lists have been published. There is a claim that it is in beta, but no one on their fairly active forum will admit to being part of the beta group.
  • Affinity: Similar to Luminar.

Commandline tools

Much of the special features for version tracking could be implemented with scripts using calls to these programs.

  • ImageMagick -- good for whole-image conversions, also can read/write internal metadata and sidecars.
  • Exiftool -- read/write exif data reads most makernotes.
  • fswatch -- not really an image processor, but hooks into the operating system and can alert when files have changed -- modified, renamed, moved.
Enterprise level

There are a raft of these with vaguely defined abilities and very high price tags. Most are SaaS and cost hundreds to thousands of dollars per month. Once I saw a large price tag, I stopped considering it.

  • WebDAM No real information about capabilities on web site.
  • Extensis. Expensive.
  • Bynder. Joke program. Cloud based set of shoeboxes.
  • WIDEN. Cloud only.
  • Asset Bank. Starts at $500/month for up to 50 users.
 
Link to comment
Share on other sites

34 minutes ago, sgbotsford said:

I've been thinking a lot about photo management.

As have I and you seem to have nailed it. I will read this again but first time through I think you hit all the needed features and potential pitfalls.

Mac Pro (Late 2013) Mac OS 12.7.4 
Affinity Designer 2.4.0 | Affinity Photo 2.4.0 | Affinity Publisher 2.4.0 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Link to comment
Share on other sites

1 hour ago, sgbotsford said:

Nothing I've found supports version tracking, especially through an external program.

AFAI recall that free (opensource) digiKam supports versioning since longer time, though I don't know if maybe also through an external prog.

However, lately it's somehow en vogue for RAW converter vendors to also jump into the image management theme, so most of them plunge(d) into this now and put on more or less something into their existing products here. Though obviously not all primary RAW converters are that good suited for such later applied add-ons and thus certain implementations aren't very intuitively usable. In short, it's still a recognizable difference here, if something has been build up from ground up to be more an image management software, or instead primary a RAW converter.

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
Share on other sites

6 hours ago, sgbotsford said:

Proprietary formats is a good way to fail as a business.

Right! That's why Illustrator has been such a dismal failure for Adobe. ;)

All 3 1.10.8, & all 3 V2.4.0 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

FBX ....The entire 3D stock vaults market and a bunch of game engines depend on it. Utilities and importers/exporters are constantly broken due to the format's version changes, and often there's no solution.... I guess if all would be FOSS in that front, the company (Autodesk) would loose a lot of market advantage. IE, Blender could do much easier any importer or exporter.... And PSD's most native features are what keep a lot of pro users from going all the way with alternatives.... For some reason (well, that FBX is a main export format for Max/Maya), Collada's DAE, being open and all, still has nowhere near the level of installed user base in everything that FBX has. And you would think it should be decreasing due to collada being more complete and open.... WELL...not the case, and I believe is a decade or more since I'm hoping for it... In the end, the format does not decide, I mean, it often has not so much value by its own self : Is the tool which reigns the market what counts. Everyone and their dog will want the format that the main apps in business are using, that's the type of files that are being mostly used in every day work. And in commercial software, this is going to be native files, closed proprietary formats. Sadly, but it is how it works.

AD, AP and APub. V1.10.6 and V2.4 Windows 10 and Windows 11. 
Ryzen 9 3900X, 32 GB RAM,  RTX 3060 12GB, Wacom Intuos XL, Wacom L. Eizo ColorEdge CS 2420 monitor. Windows 10 Pro.
(Laptop) HP Omen 16-b1010ns 12700H, 32GB DDR5, nVidia RTX 3060 6GB + Huion Kamvas 22 pen display, Windows 11 Pro.

 

 

Link to comment
Share on other sites

As an example of the flip side, look at Microsoft Docx format.  Everyone can read it.  Many apps can write some form of it.  Ditto Excel.  They aren't losing market share.

 

Adobe is a crap vendor.  Their user interface is inconsistent, software buggy.  Photoshop mangles metadata it doesn't understand.    Every mac owner knows to their pain to not install a new OS-X version for half a year after it comes out because Adobe apps will break. (We've been down that road with InDesign.)  Their product support is awful.  (See FrameMaker; Flash)

 

AFAIK Illustrator uses a subset of postscript as it's internal format.  And PS is mostly a write only format.  There are many ways to do things.  (In fact PS is an actual programming language -- it's Turing Complete.  In principle you can write an operating system in postscript. )

 

 

Link to comment
Share on other sites

Still clinging to life with Aperture and was doing my biannual check to see if Affinity had added asset management to Photo yet. Pretty much in a need a lighter version of what @sgbotsford elaborated on above. Have been hoping to give Affinity a shot but it's useless to me without the asset management and meta data end of things. I'm upgrading my camera body soon and unfortunately I think it's going to break Aperture usability for me, so I'm really in need of a replacement. Don't care for Lightroom or Adobe's subscription model (or being tied to another one of their products for anything), so it's looking like I'll have to give Capture One Pro a shot instead.

Edited by ShadeDream
Link to comment
Share on other sites

8 hours ago, sgbotsford said:

Adobe is a crap vendor. 

Crap or not, actually fully having the market, almost entirely. The other big massive monster is Autodesk. Among the two, they have almost all the fields in 2D and 3D, in the professional world and whatnot. 

This might seem irrelevant when considering the technical aspects or efficiency of an app or an UI, but, IMO, in the end is key, and all what ends up counting. I believe there are rarely so good -yet minimalistic UI- and efficient low polygon count modelers such as Wings 3D. Silo while it was alive, Modo is cool, but is not IMO as fast in some aspects (Modo is another beast, much more complete, a dream come true.  I'm speaking only about a certain type of modeling). And modeling low / mid meshes is absolutely key for everything, be it games , animation, etc. But the market is everything. The market is Max, Maya,  Cinema, Zbrush (and now Modo and 3D Coat) Just like I also think Collada is a superior -technically- format, indeed, than Autodesk's FBX .  It stores the whole scene in every possible bit, if the plugin is well implemented.  A better technical product is often literally destroyed by the massive numbers of the top dog. Also, I dunno. I've used trials of CC 2018, not yet 2019, and IMO are quite good... Just as I think Affinity UI is very good too, just slightly different.

About MS : I've had some serious problems with compatibility of some files (docx , excel files, and mostly MS Publisher files) sent to me by my clients (with specs, mockups for me knowing what to do, list of items, descriptions, etc). Them having MS office, me handling latest stable (always) Libre Office... And that's one software that has made big efforts to keep it compatible... This kind of interaction is IMO safer of surprises when using Google Docs (not a fan of online tools, tho, by any stretch).

AD, AP and APub. V1.10.6 and V2.4 Windows 10 and Windows 11. 
Ryzen 9 3900X, 32 GB RAM,  RTX 3060 12GB, Wacom Intuos XL, Wacom L. Eizo ColorEdge CS 2420 monitor. Windows 10 Pro.
(Laptop) HP Omen 16-b1010ns 12700H, 32GB DDR5, nVidia RTX 3060 6GB + Huion Kamvas 22 pen display, Windows 11 Pro.

 

 

Link to comment
Share on other sites

I have tried Libre Office and Open Office.  In some cases I found them 'bug compatible' -- the same problems I had in Word, I had in them.  I'm not impressed.  When I tried their database application -- purportedly a replacement for Access, I averaged about 3 minutes between crashes.

OTOH I've yet to have major issues with Google Docs opening Word doc and docx files. nor Google Sheets opening excel sheets.  True:  Not all functionality survived the round trip.  Word does a lot of things that Docs doesn't.  And Excel has functions and formatting features lacking in Docs.

By comparison there are MANY apps that can both read and write PSD files.  Likely also with things that don't survive the round trip.

 

Link to comment
Share on other sites

  • 6 months later...

Just bought a brand new Asus Gaming computer and now my lightroom 6 is not working properly, I have to turn off my Gpu and even then I have issues with Topaz and Lightroom working together.

So now I have to decide am I going to pay for a subscription to Lightroom or hobble along till Affinity comes out with a replacement for Lighroom. I did look into Luminar 3 & 4 but they seem to be having some big issues looking at their forum.

So Please Affinity help us out and let us know if your coming out with a Lighroom Replacement?

Link to comment
Share on other sites

39 minutes ago, BluestarCK said:

So Please Affinity help us out and let us know if your coming out with a Lighroom Replacement?

Hi @BluestarCK,

as you may have noticed by posting in this thread there is a plan to come up with a digital asset management software at some point. But you won't hear anything more detailed from Serif before they are ready to start a public beta (as they did before).

The latest comment on the topic is from just a couple of hours ago:

d.

Affinity Designer 1 & 2   |   Affinity Photo 1 & 2   |   Affinity Publisher 1 & 2
Affinity Designer 2 for iPad   |   Affinity Photo 2 for iPad   |   Affinity Publisher 2 for iPad

Windows 11 64-bit - Core i7 - 16GB - Intel HD Graphics 4600 & NVIDIA GeForce GTX 960M
iPad pro 9.7" + Apple Pencil

Link to comment
Share on other sites

What the naysayers don't seem to understand is that an integrated DAM/RAW Processor/Pixel Editor is essential to maintaining a start to finish non-destructive workflow, and that nobody has come closer to this than Adobe, and even LR and/or Bridge still haven't gotten it right. Affinity has a better chance of taking on Adobe because they're doing it from the ground up. A DAM implementation should have been their TOP priority. Crowds of visual designers would have swarmed to Affinity and Adobe would be shaking in their boots by now. But they went the way of iPad apps instead, and too many ignorant folks say they don't see the point of a DAM app. Maybe they're ok with having dozens of versions of files in a mix of proprietary and destructive formats, floating around on an archive of hard drives, but high production pros know the value of a database-driven library where you can do it once and always know where to find it when it's time to go to the next step of the project. NON-DESTRUCTIVE workflow is the key.

If Serif is brave enough to dive in all the way they'll reap the rewards. Until then, thousands of users will keep the Affinity suite at arms length if they can't see an end-to-end commitment.

Link to comment
Share on other sites

17 minutes ago, tallrob said:

What the naysayers don't seem to understand is that an integrated DAM/RAW Processor/Pixel Editor is essential to maintaining a start to finish non-destructive workflow...

What you do not seem to understand is that not everyone needs anything like that for their workflows, whatever they may be. Many are content with (or even prefer) using several different apps, sometimes from several different companies, often because one company's apps do not do some things they want to do as well as some others.

25 minutes ago, tallrob said:

A DAM implementation should have been their TOP priority.

Why? It takes years to develop even a semi-usable beta version of something like that, & years more to develop that into a retail version that could compete with existing products. Their top priority must always be to stay in business long enough to do that, so how do you propose they could have done that without the profits from the retail products they have been developing?

All 3 1.10.8, & all 3 V2.4.0 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

49 minutes ago, tallrob said:

high production pros know the value of a database-driven library where you can do it once and always know where to find it when it's time to go to the next step of the project

It's more complexe scripts and API to archive documents by pages and more, with a huge database to find authors of illustrations or articles, etc. and interface to browse and command, if you've got the rights to, the elements you want to reuse. No LR or Bridge there.

Link to comment
Share on other sites

1 hour ago, tallrob said:

What the naysayers don't seem to understand is that an integrated DAM/RAW Processor/Pixel Editor is essential to maintaining a start to finish non-destructive workflow, and that nobody has come closer to this than Adobe, and even LR and/or Bridge still haven't gotten it right. 

That's not true. There are several alternatives to Adobe's suite now, like Capture One, Exposure, On1 that provide very similar functionality t what Adobe provides -- and in some cases superior. On1 and Capture one both have a better reputation as far as the final image goes, and both are closing the gap on asset management where it still exists with impressive alacrity.

I've been using On1 for most of my asset management since Luminar has been so buggy and nigh unusable, and using Topaz, Imerge, or Affinity for more sophisticated retouching.

Affinity doesn't NEED to provide a DAM, because it's obviously doing pretty well with its current products, but it doesn't seem to be gaining much traction with professionals. I'd be pretty pleased if Affinity DID introduce a DAM especially if it does as good a job as with Photo and Designer, but for now I'm just happy that I have access to a great editor that doesn't require giving more money to Adobe's empire of mediocrity.

Link to comment
Share on other sites

  • 7 months later...

Just been pointed to this thread.

The very simple reason I would like an Affinity DAM is because Serif have proven that they know how to build great software, and the same reason Adobe built Lightroom is a reason for Affinity to build a "darkroom" product. I'm sure there are photographers who use Photoshop to process RAW files, but I reckon an awful lot more use Lightroom because that's what it is designed to do. I believe both the Photoshop and Affinity Photo names are less than ideal. Both products are way, way more than photo-based tools, and because of this, they aren't well geared to a photographer's workflow. Indeed they shouldn't be.

In my past and/or current repertoire of "darkroom" applications are: Lightroom, Aperture, Luminar, PhotoLab, ON1, and Apple Photos. Aperture is no longer for this world, and without it nothing equals Lightroom when it comes to managing and processing photographs. Lightroom I now find boring, but it can't be beat as an all-rounder (subscription pricing aside).

Luminar is a capable processor with some interesting processing features (not including sky replacement) but its DAM is barely there. PhotoLab has fantastic RAW conversion, a good feature set, and its DAM is workable, but with some critical issues. It also has some severe performance issues. ON1 is a decent all-rounder, most closely matching up to Lightroom but not quite there just yet, and bettered in some areas by others in my list. Apple Photos ... not sure why I included it in the list to be honest, but it does have a DAM. Why? Because Apple recognise that photos need a place to live where you can find them again. 

But... try putting a 100 MB, 24 megapixel, 16 bit, full colour TIFF scan of a 35mm slide into any of these applications and they struggle. Again, Lightroom is capable. Some of the others almost seize up. One of them actually crashed my computer. Put that same TIFF in Affinity Photo, whack a new pixel layer on for non-destructive workflow, and use the infill brush to remove hundreds of dust specks and it doesn't even break a sweat. And I can do it on my iPad with a Pencil, too! Affinity product performance is next level.

For an Affinity DAM, I would not be surprised to see jaw dropping performance with great workflow, and, of course, fantastic integration. Imagine Selecting "Place" in Publisher and having your DAM library as an option to pick the file - just like Apple do with Pages and Photos.

However, the current Affinity RAW conversion appears to be relatively basic. Elsewhere, I asked that Serif buy the technology developed by DxO for PhotoLab 3, because it does astounding things with RAW files. By profiling actual lenses on actual cameras they are able to bring out razor sharp images that no other product in my list, nor Affinity Photo, can do. Their noise reduction is the most impressive I've seen, too, because it de-noises the RAW data based on those same camera and lens profiles, not the decoded image like everyone else does. When it comes to clever coding, fantastic implementation, and next level performance, Affinity products have it in spades, but DxO put some leg work into working with the hardware that is providing the images and it shows. I don't expect Serif to go that far, but the results speak for themselves. 

Link to comment
Share on other sites

  • 3 months later...
On 3/13/2019 at 2:26 PM, sgbotsford said:

I've said this before, but it bears repeating:  

 

Introduction

Currently using Apple Aperture. Need a replacement.

I've been thinking a lot about photo management.

....

 

Bravo. If Serif would just basically rebuild Aperture minus the bloat, their suite would be a miracle product and Adobe would feel it.

Link to comment
Share on other sites

  • 1 year later...
On 2/14/2019 at 11:37 PM, Alfred said:

I feel the same way, but it seems that some people find the idea of a tightly integrated set of tools particularly attractive.

This seems to contradict the function of a DAM, that is an aggregator of heterogeneous types of data.

Paolo

 

Link to comment
Share on other sites

  • 2 years later...
On 12/20/2017 at 9:59 AM, MattP said:

I know I'm arriving at this party very late (because I didn't see it until now...) but nobody is trying to 'not answer' anything and there are no 'difficult questions' - there are only questions that some moderators may not know the answer to as they're not privy to all information. I'll say this: I'm sitting next to the guys that are writing the DAM... It's a thing.

Any more news on this?
Is it live or dead?

www.JAmedia.uk  and www.TamworthHeritage.org.uk
[Win 11  | AMD Ryzen 5950X 16 Core CPU | 128GB Ram | NVIDIA 3080TI 12GB ]
[MB ASUS ProArt B550| C Drive:; 1TB M2 980 Pro | D Drive; 2TB M2 970 EVO ]

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.