Why not?
Why does MP not just use the C1-generated .cop proxy instead of rendering there own preview which it is horrible at?
(Oh and I have contacted PO about this)
(Oh and I have contacted PO about this)
0
-
I wouldn't know.
What did they say?0 -
What we say is that MP is a derivative of Expression and iView.
Hence something like this would be rewriting the software AND people that is using MP only and not CO would not be happy about this change since it would change performance in a negative direction.0 -
[quote="Ulf" wrote:
What we say is that MP is a derivative of Expression and iView.
Hence something like this would be rewriting the software AND people that is using MP only and not CO would not be happy about this change since it would change performance in a negative direction.
True. However, it would be interesting to know how many people that use MP and don't use CO actually render their photos with the CO engine. I'd guess few.
That would leave an option of using the CO engine only if you actually used CO - and then use the existing/generated .cop files . I would think that this would eliminate headaches and make the coding and updating a lot easier.0 -
but is seems to be a bad adoption of what iViewMedia from version 1 to 3 was, and even under the "evil reign" of Microsoft as EM2, these issues never occurred:
All tage were properly "read out" and "wrote to" - and yes, compared to MP 1.3 and MP 1.4 crashes, errors, and wrong values in iViewMedia and EM2 never occurred!
saludos redondos -
tom0 -
I wasn't targeting you, Ulf, when i wrote that. It seemed to me that, in a user-to-user forum, a user could share what the vendor of the product had said/written in a support case when one complains about the issue in the forum.
Thanks for the reply though.
I share much of Jim MSP's opinion though. When you think about it, what's the point in using the CO rendering in MP when you don't have CO? It seems rather pointless to me, unless this opens the door in the future to choose other render engines than CO.
Now, that would be a real treat if you ask me, especially if one could choose the render engine per image/version.
How's that for a feature request 😄 😄 😄0 -
It makes absolute sense for Phase One to offer Capture One rendering. They own the product and users of CO7 want to see how their images look with Capture One adjustments. For an Adobe/Media Pro workflow you have to use DNG to get the same benefit (as you did with iView). Seeing only the embedded JPEG inside a raw with Media Pro can be frustrating, especially for B&W images.
As to why Phase One don't use the cop proxy well Ulf suggested it's not practical. I offered both the previous owners of this program several feature suggestions with some being implemented, others being pipedreams! BTW one of those pipedreams was to apply raw edits to proxies when not attached to the originals - which Phase One have now managed to do it in their other app CO7.0 -
Hi,
I guess it would make perfect sense to use the CO .cop files for viewing catalogued images.
At this time CO users who also use MP will see the mega slow rendering of images every time they use MP.
When the .cop option is used this won't be an option and for MP only users, generating a .cop file only has to be done one while importing their images or when rebuilding the catalogue.
Saying the MP is a derivate of iView and EV only tell us that it will keep building on old technology while CO evolves into a more and more mature product. Also if the image is adjusted in CO (the .cop file is rewritten) all that is required for MP is to reread the .cop file, updating the preview with the current procedure is not as productive (read: is a rigmarole) as I would like to see.
I still don't use MP yet, is because of the slow preview rendering.
cheers,
Ron0 -
[quote="Ulf" wrote:
What we say is that MP is a derivative of Expression and iView.
Some definitions of "derivative" are "imitative of the work of others" and "lacking originality". That was certainly true of the Microsoft version of Media Pro, which was one step up and two steps back. Unfortunately the evidence so far is that for Phase One the same is also true.
For my DNG based workflow I find it alarming that iView Media Pro v3, which is nearly 8 years old, is faster, easier to use and so so much more reliable than Phase One Media Pro v1.4. One day I'll post my Media Pro wishlist, which contains things that Phase One should aspire too and things to fix or remove that they should be embarassed by.
IanMy only caveat is that I have to run an old version of Quicktime to get around a Windows 8+3 filenaming bug that occured around 7 years ago. But as I don't have an iPlod or iFad and use VLC to watch movies this isn't an issue.
0 -
I allway use MP or formerly EM2 or more formerly iViewMedia to do the initial step in my workflow.
1. Import all raw-files - Nikon, Canon, Panasonic, Sony, Leica in an entry catalogue per year.
2. The annual catalogues contain each between 20,000 to 50,000 pictures - without any lack of performance.
3. I tag the raw files and rename them.
4. Then I built new sub catalogues inside each annual catalogue - or just add newly shot pictures to existng sub-catalogues inside each annual catalogue, after I deleted those files which are really no keepers or bad or oof, or whatever quality means is in need.
5. Regarding dedicated jobs or groupings or whatever topics to organise the pictures structurally I then sleets these portion/sub catalogues, marl these files and build a separate catalogue from these selected files and temporarily store this sub catalogue for the only use as an intermediate source to import this portion into COne - taking care, that later on I am able to rebuilt this selection. All these exported sub catalogues contain al necessary metadata already with the aim, never to touch metadata inside COne.
---
6. I open a new referenced catalogue with COne, name it exactly like the sub catalogues existing as a source in MP in let COne import the "files" by "Import From catalogue ... MP catalogue.
7. After this import is done an the catalogue is stored with the dedicated portion of the job or topic or grouping and delete the temporarily stored MP sub catalogue which is only used for the reason to import - the portion still exist inside the annual master MP catalogue.
---
8. Now I have my COne catalogues which only consist of the pictures in need to do the dedicated jobs - these COne catalogues are at a size that is easy to handle. The only down might be that I need a structured folder system to store them, but e.g I shoot a wedding of "Alice and Bob" I do not need files from the wedding of "Isabelle and Joe" inside this catalogue.
9. As mentioned above, I never try to change or add metadata inside COne - I only may need the already embedded metadata to control and/or select portions put that catalogue, e.g. assuming that the wedding or event of interest last longer then one day or I have collected files regarding on specific topic, that are spread over months or years, e.g. constructions of a facility, that last over let's say 2 or 3 years and pictures are taken several times within each year.
10. Additionally I do not need to synchronise the COne catalogue with MP catalogue, because this would produce redundancy, the really fast might lead to confusion as well as producing overhead in just synchronsing. I know that the edit steps ares stored inside the COne catalogue and I do not need to have those edit steps stored inside the MP catalogue. Remember the old day, where negatives were used: no photographer in the world ever reproduced the prints and collecting them as additional negatives along with the original negatives 😊)
---
11. If customers like r are in need of a MP catalogue of their resulting digital pictures from my workflow, I am able to build a new MP catalogue with those edited pictures and hand this catalogue to the regarding customers for further use.
Nothing more I need - besides a little bit more stability :-==)
saludos redondos -
tom0
Post is closed for comments.
Comments
9 comments