This attitude won’t get you very far with folks on the PPC or early Intel forums.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Camera raw updates for Leopard?
- Thread starter fluidhd
- Start date
- Sort by reaction score
This attitude won’t get you very far with folks on the PPC or early Intel forums.
Sorry, I'm not
I have no idea what to do with the Portfile, and to give you a clue, I don't even have X11 installed. Sorry I thought this was some sort of contained and compiled test build. I'll go back to my BASH 101 lessons and watch from here.
(To be honest, it is probably not worth spending time on, if the only aim is to try rawstudio port.)
If you will want to do it anyway, install Macports, make an overlay repo and add it to sources (see the post I referred to), make a folder graphics there, place there my port. You should get OVERLAY/graphics/rawstudio/Portfile. Patches are placed in OVERLAY/graphics/rawstudio/files. Sync ports again: sudo port -v sync, then custom ports from overlay repo are added. Then sudo port -v install rawstudio.
On Leopard you do not need any special manual settings, everything should work out of the box. I can reply to specific questions, if there are issues in the process.
Alright, I gave it my best but I really have no experience with MacPorts and I'm still not even sure what it is. I did the install command and my terminal seemed to be downloading...for about four hours until I pulled the plug. I currently get about 800-900MB/s down, there is no way it could be that big. I wish I could do more, but I've given up. It's not for me, as I just don't have the understanding to even begin.
If it’s your very first time installing macports, it can take some time (and yes, some space) to set up the port environment and to download all the port descriptions. On my late 2005 PowerBook G4s (well, one of them, as the other is a SL-PPC test mule), the first time I set it up took several hours. That set-up time is not atypical, but once in place, the updating of port descriptions (i.e., “port selfupdate" command) takes a few minutes, at most. This ought to be done every couple of weeks (macports will remind you to do this if you run a “port” command more than two weeks since the last time you ran a “port” command).
As to the more important question: all macports is is a platform to install open source command-line software and open source GUI software — much of it licensed as GNU and free software. Much of this software is also used in Linux environments.
For the latter, you can, for example, port-install VLC instead of downloading it as a .dmg. This can be handy if you want to set up VLC with special, custom functions which may not be bundled in the standard build provided by videolan-dot-org. For the former, you can install command-line software or libraries which can be very handy to have for other things later on.
Think of macports as a command-line App Store — except none of it is commercial and all of it is supported by the open source community.
Well that kind of answers a need/question I had but didn’t get around to finding: since Leopard is officially UNIX compliant, shouldn’t it be compatible with UNIX scripts and programs, and wouldn’t that mean even some modern programs could run on old Leopard?
I’ll try again, though still certain I don’t know what I’m doing.
I’ll try again, though still certain I don’t know what I’m doing.
These modern programs may depend on something that simply isn’t there in Leopard. Trying to compile newer software for an old environment can hit roadblocks.
Large portion of opensource software does build for Unix, MacOS and Linux. Some require OS-specific functionality, and that may not work.
You can compare ports for MacOS: https://github.com/macports/macports-ports
OpenBSD: https://github.com/openbsd/ports
NetBSD: https://github.com/NetBSD/pkgsrc
FreeBSD: https://www.freshports.org
Thanks for helping derail the thread 😅 But actually, thanks for confirming my suspicion that some ‘nix software can be ported easily.
I successfully (I guess) downloaded all of the dependencies etc for the RAW app, but now I’m at a loss. I’ve been searching and pain-stakingly trying to understand what to even do with the Portfile, but it’s all Chinese to me. Nobody gives a clear step-by-step guide on how to port these apps, so it’s beyond my ability to understand.
The best I can offer is that I’m running 10.5 on Intel and will be willing to try out any easily installable or configured software to test.
Still wondering what OP will be doing since his G5’s sad fate. Regardless, I think this would be beneficial for the PPC guys in the end.
I successfully (I guess) downloaded all of the dependencies etc for the RAW app, but now I’m at a loss. I’ve been searching and pain-stakingly trying to understand what to even do with the Portfile, but it’s all Chinese to me. Nobody gives a clear step-by-step guide on how to port these apps, so it’s beyond my ability to understand.
The best I can offer is that I’m running 10.5 on Intel and will be willing to try out any easily installable or configured software to test.
Still wondering what OP will be doing since his G5’s sad fate. Regardless, I think this would be beneficial for the PPC guys in the end.
I know OP hit a road block and may have given up but OP do you mind sending me a .CR2 if you're interested in doing a test? I have a G5 and I have GraphicConverter 7.6.2 which claims to be universal binary and support .CR2. If you send me one from your camera I can confirm for sure whether it does or does not work.
libopenraw should work, but PPC needs an earlier version, 0.1.3: https://github.com/macports/macport...0b0b7ee444dd5c864ad9ce53d/graphics/libopenraw
Re libopenraw:
It exports plugin to gdk-pixbuf, so presumably adds support for raw images to all apps with gdk-pixbuf support. This is to answer how it works. (Did not try yet, but should work.)
The current version builds fine without Rust for PPC with a minimal patch. I will open a PR to Macports soon.
It exports plugin to gdk-pixbuf, so presumably adds support for raw images to all apps with gdk-pixbuf support. This is to answer how it works. (Did not try yet, but should work.)
The current version builds fine without Rust for PPC with a minimal patch. I will open a PR to Macports soon.
I’ll give it one last go. When I did it about two weeks ago, about ten things said they failed to install and would have to do some manual something or other and went right over my head. I ran the port install command again yesterday and it just outright failed without trying after I confirmed the “install y|n?” prompt.
Perhaps wait a day, there is some issue with Macports servers now.
Just in case, a version without dependency on Rust: https://github.com/barracuda156/macports-ports/tree/openraw/graphics/libopenraw-legacy (this will build for PPC).
If you are not in a hurry, just wait until my PR is merged, and then it can be installed normally with sudo port install.
Otherwise set up a local repo: https://guide.macports.org/chunked/development.local-repositories.html
Then you need to put my portfile and patches into LOCAL_REPO_NAME/graphics/libopenraw-legacy/
Portfile goes into that directory, patches go into LOCAL_REPO_NAME/graphics/libopenraw-legacy/files.
P. S. I perfectly understand this can be frustrating, I passed through this myself not too long ago. If you think these skills may be useful later, it might be worth putting some effort. Otherwise wait a bit; I have no control over how fast PR is approved by the port maintainer.
libopenraw, -legacy: use append with deps · macports/macports-ports@1e79d74
See: https://github.com/macports/macports-ports/pull/18307#pullrequestreview-1407155957
github.com
Should become available in Macports in a few hours.
It would be rude of me to not give the whole Macports thing ONE MORE try before giving up, since you put this effort in.
I want to drop off this tidbit.
I was previously using Raw Photo Processor in Leopard to convert RAW’s from my Sony camera. It worked rather well but the images just weren’t 100%.
This whole time I have never looked into VueScan because it does NOT advertise the ability to develop RAW negatives but it is now the BEST RAW converter for Leopard on Intel! The program is powerful and easy to automate batches. I get exactly the results I want every time. It’s FANTASTIC!
There is good news. Apparently VueScan uses dcraw for RAW compatibility.
The version I’m using of VueScan is 9.5 which was released around 2017. Still runs on Leopard and should bring RAW compatibility up to at least 2016 camera models.
There are versions of VueScan that run on PowerPC, obviously. If it is true that it is using dcraw for RAW compatibility, does that mean there’s any possible chance of updating the dcraw version within these older versions of VueScan?
I want to drop off this tidbit.
I was previously using Raw Photo Processor in Leopard to convert RAW’s from my Sony camera. It worked rather well but the images just weren’t 100%.
This whole time I have never looked into VueScan because it does NOT advertise the ability to develop RAW negatives but it is now the BEST RAW converter for Leopard on Intel! The program is powerful and easy to automate batches. I get exactly the results I want every time. It’s FANTASTIC!
There is good news. Apparently VueScan uses dcraw for RAW compatibility.
The version I’m using of VueScan is 9.5 which was released around 2017. Still runs on Leopard and should bring RAW compatibility up to at least 2016 camera models.
There are versions of VueScan that run on PowerPC, obviously. If it is true that it is using dcraw for RAW compatibility, does that mean there’s any possible chance of updating the dcraw version within these older versions of VueScan?
I think VueScan is proprietary software. If it can use external copy of dcraw, that should work.
dcraw itself should build: https://ports.macports.org/port/dcraw/details
ufraw on top of it may be promising: https://ports.macports.org/port/ufraw/details
Not sure if builds, can check tomorrow. Ping me here.
If it is broken, I can try to fix. Given dependencies, it should work.
Re Macports: if users of software don’t report that something is broken, chances are slim it randomly gets fixed, especially for PPC. We have like 2–3 people with hardware to test and maybe 2 more with willingness to work on PPC, given someone tests it on hardware.
Those 2–3 people have priorities for ports and macOS versions. Say, I do not normally test stuff on 10.5, unless I have a specific reason to, and almost never on 10.4 (I won’t work on fixing something for Tiger beyond trivialities either: sorry, it is just too badly broken). My ports must build on 10.6 ppc however, and every ppc-related fix should work on 10.6. Usually that implies support for 10.5, but I can’t guarantee that.
Then, there is just no time to thoroughly test every random port or sometimes test at all, because there are no tests, or they are broken beyond feasible repair. So, say, if you want to have a functional RAW converter with support of recent cameras on PPC via Macports, this will probably require your active participation in the process by testing in your environment and for your use cases. Having such feedback will improve results for you and save developers’ time.
For instance, I have recently fixed `rawstudio` build, but it was not working on my system. If, say, it gonna fail identically on your system, we can try fixing that (as I recall, there was a missing symbol on launch; that should be fixable).
Or try `libopenraw-legacy`. Or try `dcraw` with `ufraw` and let us know what fails.
We just don’t have a facility of someone leading the thing from fixes to the build all through to production-quality solution. Help us to help you
dcraw itself should build: https://ports.macports.org/port/dcraw/details
ufraw on top of it may be promising: https://ports.macports.org/port/ufraw/details
Not sure if builds, can check tomorrow. Ping me here.
If it is broken, I can try to fix. Given dependencies, it should work.
Re Macports: if users of software don’t report that something is broken, chances are slim it randomly gets fixed, especially for PPC. We have like 2–3 people with hardware to test and maybe 2 more with willingness to work on PPC, given someone tests it on hardware.
Those 2–3 people have priorities for ports and macOS versions. Say, I do not normally test stuff on 10.5, unless I have a specific reason to, and almost never on 10.4 (I won’t work on fixing something for Tiger beyond trivialities either: sorry, it is just too badly broken). My ports must build on 10.6 ppc however, and every ppc-related fix should work on 10.6. Usually that implies support for 10.5, but I can’t guarantee that.
Then, there is just no time to thoroughly test every random port or sometimes test at all, because there are no tests, or they are broken beyond feasible repair. So, say, if you want to have a functional RAW converter with support of recent cameras on PPC via Macports, this will probably require your active participation in the process by testing in your environment and for your use cases. Having such feedback will improve results for you and save developers’ time.
For instance, I have recently fixed `rawstudio` build, but it was not working on my system. If, say, it gonna fail identically on your system, we can try fixing that (as I recall, there was a missing symbol on launch; that should be fixable).
Or try `libopenraw-legacy`. Or try `dcraw` with `ufraw` and let us know what fails.
We just don’t have a facility of someone leading the thing from fixes to the build all through to production-quality solution. Help us to help you
Maybe because you haven't fully mastered it?
I use nothing but RPP and don't even look at others with all their hidden, out of my control "enhancements". And I'm not doing weddings or cats, flowers and sunsets...
Anyway, I was going to add the following info regarding RPP versions. To my knowledge:
* Last version with PPC support was (4.7.2) 1672 - see below
* Last 32 bit version that supported 10.4-10.5 was (4.8.0) 1753
* Last 32 bit version released was (4.8.0) 1818
* Last version for 10.6-10.8 was (4.8.0) 1864
* From 1865 and to this day it is for 10.10 and up.
EDIT. As to the VueScan, I looked inside the 9.6.47 (Intel) and 8.5.4 (UB) versions and there is no separate dcraw file there, so it is probably compiled into main executable. Btw, 9.6.47 is still compiled with Leopard as minimum system and is from 2019.
Last edited:
Where did you get this info? Do you happen to have any old versions saved? Would be nice to add to the archive.
RPP is just too much dialing in and faffing and just when I think I have it right the next series of photos comes out different. Even doing the batch convert is a bastard. Have to save adjustments to the history then propagate or whatever I can’t even describe it because I actually haven’t nailed it down I just repeatedly click around until it actually does it. The manual is unclear and confusing. Worst part about any manual is when something is clearly explained…and it’s wrong. The frustration…
I put a Sony ARW into VueScan and it instantly came out looking FAR better than I ever managed with RPP and superior to Adobe Camera RAW’s dreams. It’s unbelievably easy to batch and tweak and integrate into other apps etc. I see no reason to bother with any other conversion software since VueScan works (consistently and similarly) for scanning, printing and conversion. It’s the all-in-one tool. My workflow is currently digital/analog negatives>VueScan>Aperture and done.
RPP is just too much dialing in and faffing and just when I think I have it right the next series of photos comes out different. Even doing the batch convert is a bastard. Have to save adjustments to the history then propagate or whatever I can’t even describe it because I actually haven’t nailed it down I just repeatedly click around until it actually does it. The manual is unclear and confusing. Worst part about any manual is when something is clearly explained…and it’s wrong. The frustration…
I put a Sony ARW into VueScan and it instantly came out looking FAR better than I ever managed with RPP and superior to Adobe Camera RAW’s dreams. It’s unbelievably easy to batch and tweak and integrate into other apps etc. I see no reason to bother with any other conversion software since VueScan works (consistently and similarly) for scanning, printing and conversion. It’s the all-in-one tool. My workflow is currently digital/analog negatives>VueScan>Aperture and done.