| Sign in: |
| Members log in here with your user name and password to access the your admin page and other special features. |
|
|
|
|
|| SportsShooter.com: Member Message Board
Photo Mechanic 4.4.1 out Feb. 1, 2006
Steve Mitchell, Photographer
|
Steven Georges, Photographer
 |
Long Beach | CA | USA | Posted: 5:47 PM on 01.31.06 |
| ->> When will it correctly display RAW files as sharp as the jpeg's? |
|
Greg Ferguson, Photographer
|
Scottsdale | Az | USA | Posted: 6:00 PM on 01.31.06 |
->> "When will it correctly display RAW files as sharp as the
jpeg's?"
It won't until it renders the RAW file, and Kirk has said many times that is not likely because of the overhead required to load and redraw the image. Doing so would make the program go to a crawl.
The RAW images look soft because what you see is based on the preview jpeg (thumbnail) embedded in the file, either by the camera, or by a RAW conversion program that was upstream to PM. If you're running a conversion program ahead of PM, you can usually tell it to generate a bigger preview, which PM will use, but then you have a slowdown at that point in the workflow.
If you want more info, check in with the CameraBits folks at Rob Galbraith's Photo Mechanic forum. |
|
Joshua Prezant, Photographer
|
North Miami Beach | FL | USA | Posted: 7:01 PM on 01.31.06 |
| ->> Any idea as to when they will come out with the universal version that will run native on the new apple Intel chips? |
|
Greg Ferguson, Photographer
|
Scottsdale | Az | USA | Posted: 7:53 PM on 01.31.06 |
| ->> Patience will be rewarded. |
|
Kevin M. Cox, Photographer, Assistant
 |
Round Rock (Austin) | TX | US | Posted: 8:08 PM on 01.31.06 |
->> Hey Joshua, here is Kirk Baker's reply on the Galbraith forums when asked about PM being a Universal Binary:
"I have had versions of Photo Mechanic built as Universal since mid-June of 2005. We had no plans to release it until there were actual shipping systems. So version 4.4.2 will be offered in a Universal Binary format." |
|
Joshua Prezant, Photographer
|
North Miami Beach | FL | USA | Posted: 9:16 AM on 02.01.06 |
->> About 10 minutes after I posted my question Kirk Baker from Poto Mechanic e-mailed me. THAT IS WHAT I CALL SERVICE!!!! Here is what he said:
Hello Joshua,
We are working on the Universal Binary
version of Photo Mechanic and expect to
have it released in the next week or so.
I have had Photo Mechanic fully
compatible with our developer systems
since mid June. Our iMacs with the Intel
CoreDuo processors arrived today and
we will be unpacking them and testing
ASAP...
The Universal Binary version will just be a regular upgrade. If you have a password with an updates period that already allows you to run version 4.4, then you'll get the new Universal Binary version for free. Otherwise it would be a paid upgrade just like the original 4.4 version would have been had your updates period expired. |
|
Rick Rickman, Photographer
|
Laguna Niguel | CA | USA | Posted: 7:12 AM on 02.02.06 |
->> Does anyone know if the new version has the ability to drag and drop images for ordering or positioning. That certainly would be an advantageous feature for this already wonderful program.
Rick Rickman |
|
Michael Troutman, Photographer
|
Carmel | CA | USA | Posted: 10:29 AM on 02.02.06 |
->> Rick has a great suggestion that I've heard many others wish for as well. "Drag and drop" repositioning would be a *huge* advantage for anyone using PM. I can't think of any other single improvement that would have greater impact at this stage of development. Anyone using multiple bodies and/or wanting to rename the files in a particular sequence is stuck using another program to perform this basic, critical function.
PM is the ultimate light table, but there's no way to move the images around! |
|
Bob Croslin, Photographer
|
St. Petersburg | FL | USA | Posted: 11:25 AM on 02.02.06 |
| ->> Drag and drop repositioning is needed desperately. It's the only thing PM won't do that has me occasionally double-clicking on my very old version of iView - especially when building web galleries for client selects. |
|
Greg Ferguson, Photographer
|
Scottsdale | Az | USA | Posted: 11:41 AM on 02.02.06 |
->> "Anyone using multiple bodies and/or wanting to rename the files in a particular sequence is stuck using another program to perform this basic, critical function."
I use multiple bodies, sometimes have two people shooting, and rename the files all the time using PM, so I'm not sure what's being requested here. PM has the most flexible renaming scheme I've seen.
I have it automatically rename during ingest to the EXIF yyyymmdd-hhmmss format and resolve name conflicts with appended letters (A, B, C...) for those multiple-shots-within-one-second collisions. In addition, during ingest I have it add EXIF info to one of the IPTC fields so I can search for images that came from a particular body or lens or with certain settings.
What it doesn't do, because it doesn't attempt to be a database or catalog like iPhoto, Aperture, LightRoom or iView Media Pro, is remember positions of images in a particular contact sheet. I'm glad because that means adding an underlying database layer which adds bloat.
If you need to group images, try assigning a rating/color-class and sort by those and turn on and off viewing of what you want (or don't want) to see. |
|
Delane B. Rouse, Photographer, Photo Editor
|
Washington, DC & Seattle | WA | US | Posted: 12:09 PM on 02.02.06 |
->> Greg-
We're asking for "Drag and drop repositioning"...say I have images names D1, D2...D10: I want them to show up in the following order:
D8
D9
D1
D3
D2
D5
........
There is no way to REPOSITION the images the way you can in PhotoShelter. |
|
Greg Ferguson, Photographer
|
Scottsdale | Az | USA | Posted: 3:24 PM on 02.02.06 |
->> Correct.
I assume two of the things people like about PM are its speed and the lightweight resource (CPU/RAM/disk) requirements.
iView Media Pro, iPhoto, LightRoom and Aperture have the feature you want but are slower and use a lot more memory (RAM) and space (disk). The capability you're asking for is a main reason why.
PM has a direct screen position to sorting-field correlation. The others don't.
What you want requires an underlying mechanism to map the image sorting field to some pseudo-sorting scheme that maintains the screen order for you. Then it has to store that data so it has some persistance for the next time you view the same set. iView uses catalog files. iPhoto and LightRoom do it invisibly, but they're doing it. I haven't played with Aperture, but from the descriptions it's doing the same thing.
There is no way to add that feature to PM without it affecting speed and size. That's just the way programming software works.
Personally, I'd use one of the other programs if I want that feature, and let PM stay as fast as it can be based on Kirk and Dennis's vision of what the application should be. |
|
Delane B. Rouse, Photographer, Photo Editor
|
Washington, DC & Seattle | WA | US | Posted: 3:41 PM on 02.02.06 |
->> Kirk and Dennis respond to the needs of their customers/clients; when they hear enough people requesting the same feature they find a way to get it done and their execution is always fantastic.
I'm no programmer so talk about "an underlying mechanism to map the image sorting field to some pseudo-sorting scheme that maintains the screen order" is greek to me. I just know that I'd really like that feature (but not at the expense of speed)
Delane |
|
Greg Ferguson, Photographer
|
Scottsdale | Az | USA | Posted: 3:58 AM on 02.03.06 |
->> In software development, speed, size on disk and in RAM and features are interrelated. Its a balancing act with lots of trade-offs.
When a company develops a product, they have to decide what features are practical and fit the "scope" of the program. Failure to do that results in a Frankenstein program that doesn't do anything well. Good developers listen and implement things that fit the overall design goal, but they also know when to say no, (and will) even if a bunch of people ask, because they know whether those features will fit in without crippling the app.
A friend of mine runs a very successful Mac OS software company that is highly respected among developers. They listen and add new features, but they also say no when they're asked to bolt something on. In managing the requests and sticking to the core-competencies they've created an excellent product which has won numerous awards.
Too often people get myopic about using one app and that app needing to do everything for them. For instance, there have been many requests for PM to automatically upload via FTP/SFTP all files as they're ingested. Why have PM do that when a mature and proven app like Interarchy can do the FTP/SFTP auto-upload now? Interarchy will do it faster without impacting PM and CameraBits can concentrate on other features.
If CameraBits can add the image reshuffling feature without impacting speed, reliability and can maintain or improve the current usability then that's fine. As a developer I know what goes on underneath the hood, and as a user I've seen that functionality break or cause apps to crawl so it has to be done carefully. It's a fundamental change to how a program like PM works and if its not implemented correctly it'll turn into a nasty kludge. That's the cost of getting what you ask for sometimes. |
|
Ron Scheffler, Photographer
|
Hamilton (Toronto area) | Ontario | Canada | Posted: 7:38 PM on 02.03.06 |
->> Interestingly, someone I know who is currently evaluating a demo of PM commented that drag and drop repositioning would be a high priority for him. While colour classifications can help, it's not exactly the same thing.
I also ran into this situation last week while editing a job I shot with two cameras. While I view contact sheets set to display images based on capture time, the timing of my cameras were slightly off. Enough so that there were a few sequences that were mixed together. Drag and drop would be a nice user option to fix these kinds of problems (then I could do a rename of the proper sequence so it would stick when viewing in other apps). Even if the drag and drop would only stick for the duration that contact sheet is open, I would be satisfied because it would allow for renaming to 'lock' the sequence. One solution is to photograph a clock with each camera at the beginning of the job and then use PM to adjust the capture time based on the time shown on the clock.
I'm excited about Code Replacement!
Also, guys shooting a lot of volume where it's necessary to ID lots of people on a recurring basis (like if you shoot the same team on a daily/weekly basis, etc.) should look into the Code Replacement feature. While it's a bit difficult to quickly explain, it allows you to link letter/number "code" sequences you enter in any IPTC field to a text file on your computer that correlates the codes to names or whatever... So, if you have to caption an image of #67 Kimo von Oelhoffen (on the Steelers), you could set up the reference file with pit67 Kimo von Oelhoffen and in PM 4.4.1 all you'd need to type is pit67 and it will automatically replace that code with Kimo von Oelhoffen. (There are a few minor details I left out of this, so it's best to reference the instructions with PM or on the PM forum at Rob Galbraith) So, some time spent setting up a text file before a game or the start of the season could save you a load of time writing captions and double checking the spelling (just remember to update the reference file to reflect roster changes!) |
|
Gordon Grant, Photographer
|
East Hampton | NY | USA | Posted: 8:06 PM on 02.03.06 |
->> A simple list view would be great, just to quickly check IPTC info that has been added or not added.
gg |
|
Monty Rand, Photographer
|
Bangor | ME | USA | Posted: 10:36 PM on 02.03.06 |
| ->> Gordan, that would be excellent, I second that!! |
|
Andy Mead, Photographer, Photo Editor
|
Durham | NC | USA | Posted: 12:55 PM on 02.13.06 |
->> I just want say that the new code replacment feature rocks!
Great stuff. Kudos to the PhotoMechanic team. |
|
Return to --> Message Board Main Index
|