I use a workflow where I use Acdsee to manage my images, and call Photolab and Nik Collection from Acdsee. Gives me lots of options. However, since Nik 5.2 some Nik apps (including Silver Efex) can no longer be seen by Acdsee. Nik 6 is the same, so have made the decision to not upgrade and no longer use Nik collection. I tried some B&W in Photolab today and got good results. In terms of “replacing” Silver efex, I was wondering whether Filmpack would help?
Test FP yourself to see if you are happy with and compare it to Nik SilverEfex,
when you still have a licence.
Personally, I prefer Nik SEP and print via PS …
I use nothing but FilmPack in PhotoLab and get astounding results. The main advantage is that I don’t have to convert from RAW like I would with SFX.
it’s a “must have” or you’ll be missing some adjustment. when you buy PL elite you’re missing a foot plus an arm, you need viewpoint and filmpack to access all adjustment within PhotoLab, or you need a sidekick software that does it for you =]
Agreed I have never liked the idea of having to convert to TIFF. In ACDSee I used Nik Collection in layers, like Photoshop, but that is not possible anymore if I “upgrade”. I am officially weaning myself off of Nik Collection, as I already own Filmpack but haven’t used it to its potential.
Silver Efex Pro is a specialized tool for processing B&W. Optimized tools are there because they give better results faster - more effective. You say you can achieve almost the same results in PL with FP 6 and you might get a result you are happy with but that might also be a result of that we tend adapt our expectation too the tools we happen to have access to.
You can dig a big hole with a tea spoon too but it´s fare more effective with an excavator - and Silver Efex Pro is more effective I think than PL+FP 6. Often it takes just a click or two to select the preset of your choice. Even for PL users I´m pretty sure that Silver Efex Pro is the most used application of the NIK suite and it´s a good reason for that.
Each time when it comes to this topic, the same discussion starts again, which honestly is completely unnecessary. Everybody does as he / she likes, based on habits, knowledge … or just on personal preferences.
My goal is printing usually for myself, which means concerning the file size I produce ‘limited’ output. I’ve never relied on a raw-converter’s output only, but edited / tweaked the file for the intended purpose and kept the versions (or with ‘alternate’ layers) – and when optimized per print size (layout) and paper the digital counterpart for the print out.
With all that, the necessary conversion from RAW to TIFF doesn’t count for me as much as it might do for others, while a seamless integration of the Nik filters in PL would help at any time.
I like to print and have had a lot of 36 MP-files for 10 years when I bought my Sony A7r. Now quite a few produces 40, 50 or 60 MP RAW. No problem with storage since SATA3-harddiscs have been a lot cheaper over time at least in this country.
… BUT there is a big BUT here since Photolab 6 is really slow walking through ImageLibrary. The “thumbnail view” of ImageLibrary has become really slow over time despite I have a pretty new computer with a good graphics card, SSD-disk (1 TB) for both the database and my most important and postprocessed image libraries. It exports JPEG-files from 33 and 36 MP RAW in about 7-9 seconds but is irritatingly slow with the RAW-file libraries. Saving these files in 16 bit TIFF will create files that are far bigger and that is not anything I like at all.
When I test to walk between throgh 33 MP RAW it takes about 2-3 sekonds per image?n ImageLibrary mode. BUT again, if I switch to Customize mode and walk through the images in the “filmstrip” its blazingly fast. Can anyone explain that?? What´s the difference?? Why can´t the ImageLibrary get the same performance???
I have been playing around a lot more with Filmpack and and have come to the conclusion that for my purposes the majority of things I was doing with Nik Collection, which includes black and white with Silver Efex Pro, can also be achieved with Photolab + Filmpack. It does appear that most of the effects one can do with Color, Analog, and Silver EFEX pro can be more or less replicated with Photolab + Filmpack. Viveza, Sharpen, and dFine are redundant in Photolab, even though there are rare occasions where I have used dFine, amazingly enough. HDR EFEX I am not sure about, but I don’t do HDR anyway, and in any case I could always use ACDSee for that if required, since I already use ACDSee for my photo manager. So I am saying goodbye to Nik Collection. This is a good forum, as it is great to get different opinions, then make an intelligent decision.
Talking about the file size … the typical file size for edited pics,
processed in 16 bit / 360 ppI and kept with some ‘main layers’
- 42 cm long edge → 40x50 cm layout
- 50 cm long edge → 42x59,4 cm layout
ranges from 300 to 600 MB (plus 150 to 230 MB for the print version)
and can be much bigger in single cases.
But as said, the selection that makes it worthwile to be kept and printed is ‘limited’.
With a layer based editor it’s no problem to handle a (total) file size of i.e. greater than 1 GB,
as unlike in PL raw-converter there is no need to each time re-compute the whole pic.
( and we are getting even farther away from the OP )
Sure, but I´m just afraid that PhotoLibrary is going to be even more terrible to use than it is. There is something wrong with that module and it´s performance compared to the “Customize”-module.
I just tested and my PhotoLibrary can´t even handle a walk through a folder with completely plain vanilla (not edited just exported) around 3 MB of 4K JPEG-files without lagging a couple of seconds between the images. I hav no memory of version 5 being this slow, have you? I wonder what they have fucked up with the PhotoLibrary-code since then.
It is just the PhotoLibrary-module that doesn’t work properly.
if you do a search, there’s been a few thread regarding pl library issue. so it’s not new to pl5, just type pl5 library and you’ll get a list.
Some of us are regularly deleting the photo library (more to make PhotoLab read the .dop files and not rely on database) than for performance. Perhaps it would help with your performance issues too?
I know some people are but I don´t believe that is the issue really. Howcome it´s much much faster and work properly in “Customize”-mode than in the “PictureLibrary”-mode. I mean the later is supposed to be used when “culling” isn´t it? … and it is that mode that is the real pain?
Well I don´t have a real problem with that I can´t live with since I don´t use it anymore because I use Photo Mechanic for that. I´m lucky to use other tools than Picture Library but not everybody is.
I don´t see deleting the database as a serious way to handle a problem like this since it affects “Projects” and “External Seartches” that I like to use.
i’ve been using it for years now and wouldn’t look back, fastrawviewer is also popular.
it’s not hard (on mac) to do your own library. Lr had a supposed good system but i’ve had greyed out folders (nothing left in that folder) for unknown reason (on multiple occasion) that i turned to PM and i was hooked. software now basically use your folders as reference, so why can’t you do the same… the way “you” want. ¯_(ツ)_/¯
Nowadays I “do the same” and “the way I want” but there was a time before in version 5 when the sync between PL 5 and PM Plus wasn´t as good as it is today and when I for example didn´t know how to handle “virtual copies” properly as I do today.
For example, I have historical issues in some older work where RAW and JPEG-files have got metadata and virtual copies in PL 6 have not because of what I did in PL 5 - read I first postprocessed the images and sometimes created “virtual copies”. Since “virtual copies” only lives in PL they can´t be updated with metadata in PM Plus.
So, if you like I did when I did it in the wrong order even you will have to copy the metadata from the RAW even to the “Virtual copy” manually. And if you happen to have landed in a mess like that It is really important that even the thumbnail view in “PictureLibrary” is as fast as it is in “Customize Mode”, but it isn´t at all since it´s instant in “Customize” but takes 2-3 seconds per image in “Picture Library”
Today I never get in this trouble since I have changed my workflow but still I have these historical issues to take care of and that pisses me off because it is so stupid, time consuming and ineffective and really proves PL “PictureLibrary” still is in version 0.9 and very immature. I don´t know why Photolab doesn´t update both the master RAW and the “Virtual copy” because that would be a piece of cake. If it is to “protect” PM from destroying the metadata on the “copy” that might differ from the metadata on the master it should be a peace of cake handling that too but PL doesn´t even add metadata on “copies” that lacks metadata.
In PM Plus for example you can ask PM not to update the “picture taken” geometadata when adding metadata in 10 geodata elements with reverse lookup from a geodatabase CameraBits have if there already is metadata. DXO could add a possibility to prevent that with a condition and an alternative SQL-query.
Starting with the filesystem folders when indexing a folder tree is a good practise especially if the folders have descriptive names but that is just a natural starting point that have no bearing on the problems I have described above. My problem is the “virtual copies” and the way PL handles them when auto syncing the updates from PM to PL. I have no other problems really with that integration that in all other respects works beautifully.
So, my advice to you is not to make the same mistake I did earlier when creating “virtual copies” before I added metadata to all the RAW in a session. Because if you create a “copy” then the “copy” will never get any metadata when syncing with external software.
i’ve never used photo library to be honest, and none of those virtual copies neither. I’ve read many complaints that something is wrong or out of place in different threads.
hopefully DxO makes it right one day and easy to use, creating a library is simple ( i say that cause i’m not a super tech), and it’s been how long since many software started doing that, 5-6 yrs now and there’s not much development in rendering it faster =/
The only thing I´m interested in with Photolibrary and PL concerning metadata is that they don´t fuck up the metadata flow and they don´t with one exception and it is the “virtual copies”.
“Virtual copies” are essential when you use an image for different purposes and when for example exporting both B/W and color versions based on the same master RAW you need “virtual copies” and if the “virtual copy” doesn´t carry any metadata because of the problem I have described your JPEG-derivates will not do it either.
So this problem is a thing DXO ought to fix. When an update occurs in PM Plus or any other external software and PL is using metadata synchronisation it should not just update the RAW master but also all of the “virtual copies” a RAW master might have.
Maybe, but the stange thing is that performance is perfectly fine in “Customize” (Developing mode) but absolutely terrible and unusabke in Pcture Library mode.
If this discussion had taken place at Camera Biits Forums for PhotoMechanic Plus we would have had an instant explanation by Kirk Baker and a fix in a few days. Here the DXO expertice presence is just absent which makes thus forum pretty useless. If we might ve lucke this issue will be fixed in a new major release in October.
Stenis, you’re a good man, but here I strongly disagree. This forum is extremely useful as expert users can gather to share experiences, tips, workarounds in a fairly cordial environment. There are many PhotoLab users like yourself, @platypus, @mwsilvers, @Joanna to name just a few of those who take the time to help others altruistically and quite regularly.
Humans are capable of miraculous achievements when working together. This forum is a method to work together.
IMHO, DxO managers read this forum more than they let on. As you say, it would be kind of them to intervene more often. It would save a certain amount of guesswork on our part.