#Photoshop -> PageStream
43 messages in this thread
Help!
Having recently "powered up" to PageStream — largely because of its
ability to read so many graphic file formats — I find I'm having trouble
taking advantage of some artwork an associate wants me to use.
The artwork is currently on a Mac, in a variety of Mac formats. My
associate is using Adobe Photoshop (version 2.0.1, if that helps) to save
the images in various formats I *think* I should be able to use.
Unfortunately, all PageStream gives me is a "File type not recognized by
the import modules" warning.
We've tried Photoshop's output in IFF/ILBM, PCX, and TIFF formats, all to
no avail. The IFF/ILBM images were also not recognized by DPaint,
Pixmate, or show, leading me to believe there's something wrong with the
files Photoshop's creating.
Anybody have any words of wisdom for me?
Bill, I've used PhotoShop to move MAC gfx file formats to IFF and IFF > MAC
without any problems other than the square pixel requester asking to change
the IFF pixel. How are you transferring the files? I try to use LHA or
Stuffit version 1.5 to move files from MAC to Amiga or reverse, I've also
used a null-modem cable setup and term programs on both machines, it worked
fine. UNSIT on the Amiga will unpack v1.5 Stuffit files. There is a version
of LHARC for the MAC and that is very compatible with LHA or the Amiga. The
IFF output of PhotoShop should work just fine, I've used it to convert
24bit Photoshop images to 24bit IFF images and then used Art Dept. to
change them down.
chris
Thanks for your quick reply, Chris!
We're transferring the files by modem, using xmodem. Whether I have
autochop on or off doesn't seem to affect things at all. The files are
relatively small (and the fellow I'm working with relatively inexperienced
with telecommunications) so we're not compressing or archiving them at
all.
Could the version of PhotoShop make a difference? I read here recently
that Adobe had changed the format of files coming out of Illustrator and
wonder if they've done something to the file formats PhotoShop puts out.
We've been using PhotoShop version 2.0.1. (Oh yeah — GIF didn't work
either although I've used GIFs from other sources.)
It seems to me something *must* be going wrong with the save process on
the other end, but I don't know what. He says he tells PhotoShop to save
the file, then selects "Amiga IFF/ILBM" (or "TIFF," or "PCX," or "GIF")
from the File Format drop-down list. Is there something there we might be
missing?
Well, I don't remember the version of PhotoShop I have off hand. I'm not on
the right side of the country right now, but will be come Monday evening so
I'll try and check it then, I do know I have Illustrator 2.1.
I would select save AS from the FILE menu, then select IFF from the drop
down menu in the dialog box. You should be able to select the number of
bitplanes when you OK the selection. I'm wondering if your telecom transfer
is causing a problem. I can't try anything until I get home and do a few
transfers. Lately I've been using AMAX to run the MAC programs, since I no
longer have the CX I was using on the MAC side of things.
I would try and save one of the Adobe files with less bitplanes allowing
no more than 16 colors.
Chris
Bob Felts has also suggested that the problem may be too many bitplanes.
We'll give that a shot Monday morning.
(And I misspoke when I said we were "Saving" the files; we've, of course,
been "Save As"-ing them.
I'll let you know what we find on the bitplanes issue, Chris!
PhotoShop can save 256-color IFF images that are recognized by PhotoShop
and Deluxe Paint for the PC, but not by many Amiga programs… There's got
to be a way. TIFF didn't work?
I've done it, using Photoshop and Art Dept. or you can tell Photoshop to
use less bitplanes to output the file.
chris
Yes, Art Dept can handle 256-color IFFs, but your average PD viewer won't.
Yes, but AD will also reduce the number of colors too.
Then the viewers will work,
chris
Nor Amiga IFF/ILBM, nor PCX, nor GIF.
I'm at a loss unless there's (a) something we're missing in the save
process, or (b) something's different about PhotoShop version 2.0.1.
Yes, there's something wrong. Can you describe the characteristics of the
image on the Mac (num. colors, dimensions), the way you move the files from
the Mac to the Amiga, and what happens when you try to load them in Amiga
programs?
Sorry to take so long to get back to you, John.
The guy on the PhotoShop end of this mess says all the images we've tried
to transfer are 2-colors. One is 613 x 779; the other 525 x 379. Both
were scanned (using Deskscan) at a resolution of 300 dpi and saved as PICT
images.
To get an IFF file, here are the steps he says he follows:
1. He brings the image into PhotoShop, loading it as a PICT file.
2. In the Mode menu, he selects Grayscale.
3. In the File menu, he selects Save As and the IFF option. A dialog box
opens giving him a choice of how many bits per pixel. He's been choosing
two.
To get a HAM file:
1. Once the image is in PhotoShop and he's done the Grayscale thing to
it, from the Export menu, he chooses Amiga HAM. He reports that PhotoShop
"does something" (he's not sure what; I suppose some sort of conversion)
and the file is written to disk.
We then transfer the files by modem, using xmodem. PageStream says it
doesn't recognize the files.
Any guesses as to what we're missing here?
Ah, I think I see a weak spot – the modem transfer. Many Mac modem
programs (secretly) send every file out in a slightly modified format
called MacBinary. Essentially, this helps Mac users preserve the icon and
other system-related info that goes along with the data in any given file.
Look around in the terminal program to insure that MacBinary transfers are
turned off. Second, on the Amiga side, go to the CLI and do a "type
foo.pic opt h" and if you can see the true Mac filename in the righthand
column within the first 0x0200 bytes, then you've still got the MacBinary
turned on.
*Now* I feel like we're getting somewhere!
The TYPE command you suggested does indeed show the Mac filename.
Unfortunately, my colleague on the other end of the line (using a term
program called Quick Link II) can't find any options that allow him to
turn MacBinary off *and* see (and, therefore, select for transfer)
anything other than non-MacBinary files.
I'm not sure that made sense, so let me try again: In Quick Link II's
File menu, he selects Send File. That opens a dialog box from which he
selects the file he wishes to send. It also contains a check box or radio
button or something labelled "MacBinary." When that box is checked, all
the files, including the graphics files, appear in the file list and can
be selected. When the MacBinary box is *not* checked the only filename
that appears in the list is that of an ASCII file he created. There
doesn't appear to be any option that takes MacBinary files and sends them
without the resource stuff.
And we can't seem to find an option in PhotoShop to allow us to create
non-MacBinary files.
Jerry Thompson mentioned a utility to strip that strips that resource
stuff from a file, but I can't find anything in the libraries.
FWIW, I sent one of the files my associate sent to me back to him and he
had no trouble loading it into PhotoShop, so the transfer itself seems to
be working properly.
You don't turn Mac Binary off in Photoshop, but in your terminal program.
We use MicroPhone and it lets you choose between Binary and MacBinary. If
yours doesn't, you'll need a new modem program.
Michael Soft-Logik
Bill,
Have your friend download the LHARC archiver for MAC, its in the MAC LIBS
and it will stop all this trouble. If he lharcs the files first, it should
make a difference, but if his term can't send without including the
macbinary file header then I suggest he look at Microphone II for its
replacement. All the terms I have for the MAC, micorophone and White Knight
allow this option. The trouble is on his END is seems. It isn't Pagestream,
or the Amiga. Its the MAC.
cj
Are you saying that LHARCing on the Mac strips the file of the resource
fork? If so, that would, indeed, take care of the problem for us.
(And I'm *convinced* the problem is on his end. Never did doubt Ami or
PageStream. 🙂 )
No, I don't mean that LHARCing the file would strip the macbinary
header. It would preserve the IFF file and protect it from that
terminal program bent on making everything a macbinary file. But I
don't know if LHARC will be able to extract the files from it or fail
because it recognizes a "bad" LHARC file. The best thing to do it to
tell your friend to trash that term. I do find it hard to believe
that it can't send anything but a macbinary file. That just doesn't
make sense, what was the programmer thinking? Everything in the world
revolves around one file format?
Chris
I agree about the term program, Chris. The fellow's Mac expert is due
back in the office today, so we'll see if she knows how to get around this
problem.
Well, it *is* a Mac term program. 🙂
You might want to try some other terminal programs; once upon a time, I'd
use one called 'ZTerm' to link the Mac and Amiga. Your description of the
dialog box's behavior is strange indeed. The behavior, I mean, not your
description. 🙂
It's not PhotoShop that's making the MacBinary, it's the terminal program.
Why not try the floppy disk route for moving these files? There's a handy
add-on to the Apple File Exchange you can find in the Mac libraries that
makes it very clear whether you're moving a regular data-fork file or a
MacBinary data-and-resource-wrapped-together file to an MS-DOS disk. (On
the other hand, if your files are larger than a 720K disk, this isn't a
useful option, but if they're still the monochrome images you described
before, this should work well.) A program called CrossDOS is available for
less than $30, and it's even bundled with AmigaDOS 2.1. This lets you read
and write PC-format 720K disks in regular Amiga disk drives.
One last thing: sending the file back (via the terminal program) proves
nothing: the terminal program is automatically recognizing that the file is
in MacBinary format, and it's reconstituting it as it receives it. I'll
bet that it has its original icon when it comes back, right? If you were
transferring files the "right" way, it wouldn't. Funny how success could
be measured by an unsuccessful transfer, huh?
Understood, John.
We've discussed that. He's not sure his office has any Macs new enough to
have the MS-DOS compatible drives. Arrgh!
Well, I understood it would at least tell us if the xmodem transfer was
doing something to muck up the file, so that if he *couldn't* load the
file, something would be wrong.
That doesn't appear to be our problem anyway. Oh well.
We *are* talking Macs here. 🙂
Thanks for all your help!
If it's any consolation, when I wrote the PICT import that's now in the
Toaster, I made it accept both regular data-fork and MacBinary files. It's
a very easy thing to do, I'd think it would be worthwhile for Soft Logik to
implement. It doesn't hurt the regular user, takes about three lines of C,
and would save the tech support call from those six people moving images
from Macs.
The solution you crafted for the Toaster sounds like exactly what's
needed, John!
Hey, Soft-Logik! You listening?>
I had some trouble importing files scanned & processed with PhotoShop. Make
sure that you don't have too many bitplanes. I was able to change my image
to a file that Deluxe Paint would take with AD-Pro.
Good Luck, Bob Felts
The bitplanes problem sounds like a good place to start, Bob. We'll give
it a try tomorrow morning. I'll let you know how it turns out.
Thanks!
I will bet that you're problem is in the transmission by modem. Photoshop
puts a resource fork in the file. That resource fork is transmitted when
you send the file. This will cause the file to be incorrectly formatted.
If you don't know about resource and data forks and do something to get rid
of the resource fork, this will bite you every time you try to transfer
files. This happens to me ALL THE TIME when I am trying to upload files to
CompuServe. There is a font/DA mover or suitcase extractor for the Amiga
which has a program to strip the resource fork from Mac files.
If you have a high density drive and can read and write PC disks, then you
can drop the file onto the PC floppy disk. The Mac file will be written to
the disk in two parts. The %filename is the resource fork (like a .info
file), the file without the % is the data fork. Throw away the resource
fork and just use the data fork.
-Jerry Thompson
That's something no one else has mentioned, Jerry.
If I understand correctly, you're saying that if we don't do something to
get rid of the resource fork, the file will be "messed up," at least from
the Amiga point of view.
I searched the libraries using the keywords "resource" and "fork" for the
utility you mentioned, but came up empty. Can you be more specific about
what I should be looking for?
Bill,
When I've transfered photoshop converted IFF files to the amiga using a
modem, I turn off the macbinary in the MAC term program, I used Microphone
I and II. Then the mac sends it thinking its just a textfile. This should
load OK straight into the Amiga. There won't be any resource fork you need
to worry about. At least I haven't had any problems. I'm gonna do my
testing tonight and see if I can transfer a photoshop converted IFF again
and see what happens. I'll letcha know,
Chris
After following John Foust's instructions in a message he left, I'm pretty
sure we're still getting the resource fork stuff in the files my colleague
is sending me.
Our problem is trying to get rid of that stuff. Neither his term program
(Quick Link II) nor PhotoShop seem to offer any way to strip it out, and I
can't find a utility Jerry Thompson said would do it.
Bill,
I've transferred lots of MAC pics converted in Photoshop using
Microphone I & II with the macbinary turned OFF. I can't understand why
your having such trouble. I'm in the process of restoring some 80MB of MAC
files and soon as I'm done, I'm gonna fire up Photoshop and take a look.
chris
Chris, I've become convinced the problem is in the Mac's term program
*not* stripping out the MacBinary stuff, and apparently not having the
ability to do so.
The guy on the other end is checking around for another term program or an
upgrade.
Thanks for all your help!
I can't find the file but I did find an UNSIT.ARC in the Amiga User Forum
Library. If you can get an old copy of StuffIt for the Mac (I think it
used to be PD), then you could stuff the files, transfer them over the
modem, then unstuff the files using UNSIT. UNSIT will split the extracted
files into a .R and a .D file. The .D file will be the data fork. In this
case, you need to transfer stuffed archive with the Macbinary header intact
so that UNSIT can find a header to strip.
-Jerry Thompson
You know, Jerry, when we were early into this mess, we tried transferring
a stuffed file. My unstuff process ended when it came across a filename
with a slash in it, which AmigaDOS, of course, didn't like at all.
Then we got onto this resource fork thing and I never gave StuffIt another
thought.
After reading your most recent message, I tried unstuffing that one .sit
file and it did indeed unstuff a ".rsrc" file before aborting. That's the
trail we'll be following today.
Once again, thanks!
I have used PhotoShop and often save stuff in IFF ILBM or TIFF from it and
don't have problems. Maybe your Mac to Amiga conversion is the problem?
Michael Soft-Logik
It's either that or a problem with PhotoShop. Well, not PhotoShop per se,
but with the inexperience of the fellow using it.
I don't know, Michael. It's about driving us nuts. Must be something
simple we're missing.
Are there any "gotchas" we should be looking for?
Bill,
This was about IFF export from the Mac, right? When you get such a file on
the Amiga. Display the file to the Amiga screen with "type opt h
filename>". You _should_ get something like this for the first line of
it:
.0000: 464F524D 000082E4 494C424D 424D4844 FORM…dILBMBMHD
The FORM and ILBM are your clue that this is an IFF graphic file. If you
DON'T see this, you can be fairly sure that the Mac operator has made a
mistake (or that the Mac software has <g>).
If that DOES show up, then either you or your Amiga software are doing
something wrong.
Malcolm
Thanks for jumping in, Malcolm!
It looks like the Mac term program we're using is not stripping out the
resource fork stuff that makes the files MacBinary files. And we can't
figure out how to make it do it.
Bill,
Are you sure that PageStream is configured properly – is it set up with the
correct path to where the import drivers are kept? It sounds like you
can't import anything, and is this is the case, check the Set/Save Paths
requester.
Regards,
Shraddhan – via Whap! from Hertfordshire in the UK
That's one of the first things I checked, Shraddhan. The drivers are
where they belong.
Thanks anyway. I appreciate your jumping in. Any other ideas?
Bill,
My suggestion was the only thing I could think of, even though I thought it
unlikely (had it happen to me though – don't know how). I don't have any
other ideas, but there are people around here who are much more
knowledgeable of Page Stream than I am.
Regards,
Shraddhan – via Whap! from Hertfordshire in the UK
Shraddhan, I wish I had a nickel for every time I've spent time trying to
figure why a piece of equipment wouldn't work, only to finally realize no
one had plugged it in. "Forest for the trees," you know.
Thanks again!