CompuServe Thread

TAD modules

32 messages in this thread
#17220From: Christopher TolmieJun 10, 1990 10:20 PM
Perry, Just got TAD this week and I'm wondering if there is a module available for TIFF format yet? I'd like to skip trying to go to GIF and then to TIF if possible. Also, I took the image you supplied with TAD of the astronaut, converted it to grayscale, reduced it and then sized it to a 5 x 7 in ProPage and then output it on our Varityper 4300P photo imagesetter. It worked very well. I'm quite pleased with it, guess I must get the Sharp scanner now to make better images for it than I'm able to do with this Live! board. [sigh] chris AT&G
#17236From: ASDGJun 11, 1990 6:25 PM
A TIFF module is nearly complete. There are so many variations…we're trying to do most of them.
#17249From: Mike SchillerJun 12, 1990 12:29 AM
If you folks do decide to make an upgraded version of VD0 (for 2.0) and decided to keep it as a commercial program, I'd be interested in it! I'm also interested in the TIFF (or TIF as it's called in the IBM world) module. BTW, are you supporting IBM TIF's or Mac TIFF's? I understand that some bits have to be flipped or something or other like that?? (or maybe you're doing both?!!) Also, are the modules available through distributors & local dealers? Although I know it's easy to buy via mail or Email, I prefer to buy from my local dealer as a form of loyalty to him. (does that sound strange in todays world?)
#17269From: ASDGJun 12, 1990 11:28 PM
Our TIF module supports BOTH MAC and IBM formats. Also, we are supporting Pixar TIF's and NEXT TIF's (formats which have their own curves in the TIF spec). We are currently implementing TIF Group 3 FAX formats as well (a real b*tch). Modules are available from dealers (who order them directly from us). We also sell them direct to end-users. We do not sell modules through distribution however.
#17283From: John PendergrassJun 13, 1990 7:53 PM
pk, any chance of TAD ever saving the resulting image in the various formats? (ie. load Silver 24bit, save GIF format) Just curious… –jp–
#17306From: ASDGJun 14, 1990 5:01 PM
This is absolutely planned for future releases. pk
#17250From: Christopher TolmieJun 12, 1990 2:13 AM
That's great news! Put me down for one ASAP! BTW I've got the astronaut hanging on the wall in glorious 16 gray scale 2400 dpi ouput and sized at 7.5 x 9 inches and 5 x 7", it looks great from the correct viewing distance. Smaller output looks even better. Of course it took the Varityper a long time (aprox 30 min.) to RIP the two 5×7 and one 7.5 x 9 pics on one 16 x 12" page.
#17244From: Mike SchillerJun 11, 1990 11:00 PM
You'll love the Sharp scanners. I have the JX-100/Scanlab combo, and it's great! ProPage can also import 6bit greyscale scandata (at least the 1.31 version) and I would assume that it would also be able to import the 6bit greyscale from TAD. WOuld you be getting the JX100 or one of the larger units? (JX300, or JX450)
#17251From: Christopher TolmieJun 12, 1990 2:13 AM
I want the larger flatbed Sharp scanner, of course it won't happen tomorrow [sigh], gotta pay off the Varityper some more first.
#17276From: John PendergrassJun 13, 1990 9:59 AM
What's the difference between the various units? Resolution? Cost? (natually) Quality? –jp–
#17282From: David KieltykaJun 13, 1990 7:52 PM
John, The JX-100 scans at 200 dots per inch, 18 bitplanes per pixel (262,144 colors) maximum. The JX-300 and -450 do 300 dpi with 24-bit color rez (the 450 has a larger scanning area). The JX-600 does up to 600 dpi, 32-bit (I think) color. Don't know the exact costs of the JX-300 and -450, but you could probably buy a couple Amiga 3000/25s for the price of a JX-600. <grin>. I just bought a JX-100 myself. It cost around $750. 200 dpi and 18-bit color are more than sufficient for current Amiga screen resolutions/depths, but might be on the low side if you have DTP in mind. (I do regret that the JX-100 won't be able to take full advantage of the HAM-E's 8-bit greyscale mode, but even 64 greys sure beats the current 16.) Another possible negative might be the scanning area size: 4 x 6". Then again, think of the RAM necessary to scan and process 8 x 10s at 300 dpi. Fortunately, tho, scanning area size isn't a problem for me as I'll be using my JX-100 primarily to scan my own photos, and I can get (or make) 4 x 6 prints easily. As for overall quality: I imagine a 200 dpi, 18-bit JX-100 scan should be just as accurate as a 200 dpi, 18-bit JX-600 scan. Subjectively speaking, the scans I've done so far look super…better than anything I've ever been able to get with a video camera/digitizer setup. Doing all the image processing with The Art Department doesn't hurt either. 8^) I plan to upload a thing or two over the weekend in AmigaArts. Basically, I'm pleased as punch. 8^) -Dave
#17304From: ASDGJun 14, 1990 5:00 PM
DAVID, You will be able to take advantage of the 256 gray level capability of HAM-E WITH YOUR JX-100! Take a color scan (18 bit-planes) and use the Art Department's color to gray conversion. The result is an accurate 8 bit-plane gray image! pk
#17309From: David KieltykaJun 14, 1990 6:19 PM
Perry, Ah, that's nice. 8^) Thanks for the info. 256 greyscale images will be mighty fine from my POV. BTW, my TAD GIF loader came today. The disk is bad, tho…can't copy the loader to my HD. 🙁 Shall I send the disk back to you? -Dave
#17329From: ASDGJun 15, 1990 7:58 PM
I am very sorry for the inconvenience the bad disk has caused…what was bad about it? I will update you electronically on Saturday. Again, I am sorry for the inconvenience. pk
#17340From: David KieltykaJun 15, 1990 11:22 PM
Perry, No need to apologize…not your fault. 🙂 I got read/write errors while attempting to copy the GIF loader to my TAD:Loaders directory and also while trying to copy the WIZ.GIF file over to my PICS:GIF directory. The other 2 GIFs on the disk copied ok however. Anyway, sure appreciate the update! Isn't CI$ nifty? <grin> -Dave
#17351From: ASDGJun 16, 1990 12:31 PM
Your GIF module is on its way. Did the installation procedure work for you? I had a report that it didn't work for one person which I found hard to swallow. How'd it go for you. pk
#17357From: Bill EastburnJun 16, 1990 4:40 PM
It worked for me, Perry. I can't imagaine why it wouldn't work unless someone's disk was totally packed. BTW – I'll cast my vote for having the modules save as well as read in the format for which they were designed. (Not that my vote counts much. 🙂 ) I really like the program – just wish it were not so memory hungry on GIFs. Bill, K3OZM
#17359From: David KieltykaJun 16, 1990 10:00 PM
Perry, Many thanks for replacing the GIF loader. Man, that thing is fast! It used to take about 20 minutes converting GIF images to IFF using GIFtoTMP and TMPtoRGB. Your GIF loader does the job in under a minute. It also handles interlaced GIF images properly, which TMPtoRGB does not. I didn't bother with the installation program, as I knew which files I needed and where they needed to go. But let me check. Hmmm…it doesn't work from Workbench…opens up a WShell console window, reports "Unknown Command Execute," and then aborts. But it does work from WShell itself. That's odd…. Well, I've been messing around a bit and I've found the culprit. It's the SetExecute program provided with WShell. SetExecute patches Execute(), I think, to look for RunWSH rather than Run. Apparently this causes a problem with scriptfiles using dot commands, like your Install, when they're invoked from Workbench. I've removed SetExecute from my startup-sequence; I now recall having a similar problem with ProPage 1.31's installation script and never figuring out what the problem was. Perhaps that other person you mention also uses SetExecute. I've heard that ARP Execute has problems with certain scriptfiles as well. BTW, I ran DiskChk (comes with CrossDOS) on that GIF loader disk last night. It reports that blocks 71-417 are bad. I just pitched the disk. 8^) Also BTW, thanks for the correction regarding ScanLab/100. -Dave
#17364From: ASDGJun 16, 1990 11:51 PM
Thank you for the feedback. We have had problems with ARP commands not being as compatible as some people would prefer to believe. Just today someone called about our install script not working…turned out to be the ARP SKIP command. Replacing it with the Commodore SKIP command fixed the problem. Say, if you happen to have UseNet access…I could stand some kind words on that forum right about now as well. 🙂 pk
#17368From: Mark D. ManesJun 17, 1990 2:52 AM
I just bought "The Art Department" today and I am truly impressed. There is a lot to this software it does take a while to get to know it. I saw that Ben was very excited by this product, as it enhances his HAM-E product. A product that I will certainly have, and a main reason why I purchased this program. However, I find no mention of the HAM-E format in the doucmentation. Did I miss something? Anyway, pleased as can be with this product Perry. Keep up the excellent work. You do indeed give the Amiga a good name. -mark=
#17380From: ASDGJun 17, 1990 10:37 PM
Thank you Mark. There is no mention of the HAM-E in the present Art Department since TAD predates the release of HAM-E. I can assure you that we will support the HAM-E in more and more sophisticated ways as time goes on. For the present, you can use TAD as a general purpose 24 bit-plane manipulator and file format converter. For example, since HAM-E now supports 24 bit-plane IFF (as written by TAD) you can use TAD to load any format it understands and write out IFF which HAM-E now understands. Integrated support for HAM-E rendering will come in the future. pk
#17395From: Mark D. ManesJun 18, 1990 8:07 PM
Thank you for answering my question about HAM-E. A second question. I have DigiView and overall I am pleased with it. I have digitized some things so that I could see what the Art Department would do with it. I have saved the data as RAW RGB data, which I would assume to be 21 bit data. I load it using the super IFF loader. I then ask the Art Department to show me the picture by pressing execute. It seems to display the picture strangely, it shows the picture and the bottom half of the picture appears at the top. The only way I can it to show me things correctly is by doing a reduction of 50% on the heigth. Further, thinking that by feeding it a 21 bit image file I ought to get better looking stuff than when I load a normal IFF file that I saved with Digiview. Please enlighten me. I seek guidance! -mark=
#17396From: John PendergrassJun 18, 1990 9:25 PM
It appears that you are digitizing in interlace mode, and displaying in TAD in non-interlace. The entire picture is there (use the up-arrow to scroll around the pic), but you are only seeing 1/2 of if. (apparently DigiView does not create a header that tells TAD that it is a 320×400 pic (or 640×400,etc), so TAD displays in non-interlaced. In short, what you are doing is correct… now you can just set the screen format for NTSC-LACE-(OSCAN) and you are on your way! I think. –jp–
#17334From: John PendergrassJun 15, 1990 8:14 PM
Thanks for the information. A comment about your "regret that it won't take full advantage of HAM-E's gray scale"… as I recall from the Art Department, you could scan in full 18 bit color, and then go down to gray scale. That should give you more than the 64 gray scale, no? TAD should really shine on something like that. But 18bit color?? is it stored as 24bit, so that TAD imports it? I haven't heard of a TAD module specifically for their JX?? –jp–
#17341From: David KieltykaJun 15, 1990 11:27 PM
John, Yes, Perry has also said that scanning in color and then converting to greyscale will yield more than 64 levels of grey. Fine with me! 8^) The JX-100 has 18-bit color resolution, but ScanLab/100 (and TAD) save in 24-bit IFF format. The extra bits are padded out with zeros presumably. TAD loads JX-100 scans with no problems whatsoever…no special loader required. -Dave
#17352From: ASDGJun 16, 1990 12:34 PM
Actually, the JX-100 software saves only 18 bit-planes. The IFF standard (which we defined) supports any number of bit-planes which is a multiple of 3 bit-planes starting with 12. So, 12, 15, 18, 21, and 24 bit-plane files should be handled equally well by truly compliant IFF24 readers. pk
#17260From: SyndesisJun 12, 1990 10:12 AM
Did you say you wanted to go *to* TIFF? How were you planning to do that?
#17288From: Christopher TolmieJun 13, 1990 11:14 PM
John, I'd like to go to TIFF of course, but I'd also like to go from TIFF to IFF. IF you've got a IFF to TIFF module for INTERFONT, I'll buy it tomorrow (INTERFONT AND THE MODULE), but I'd also like that other module you won't sell, the ILLUSTRATOR to PRODRAW! It sure would be nice to be able to move Amiga IFF graphics to TIFF without having to try and make it a GIF file first. You have any info on this procedure? chris AT&G
#17305From: ASDGJun 14, 1990 5:00 PM
Our TIF loader is just about done. Still working on the FAX formats. pk
#17315From: Christopher TolmieJun 15, 1990 12:16 AM
Any chance that the TIF loader will also allow me to move IFF over to TIFF so I can get some large graphics from Amiga to our MAC? chris AT&G
#17331From: ASDGJun 15, 1990 7:58 PM
A future release of TAD will save in all formats that it loads. But not in the current release. pk
#17375From: Christopher TolmieJun 17, 1990 5:35 PM
pk, Well I'll anxiously await your future release of TAD then, I've been wanting to save GFX in other formats besides IFF for a long time now, but there isn't too much available in the way of programs that will do that which also don't cost an arm and a leg to do it. chris AT&G