Digital Obsolescence vs. Film Obsolescence

Status
Not open for further replies.
semilog said:
It's a Fuller Calculator.
Click to expand...

When I looked the photos, the scales appeared to be helical. It's a smart thing. I remind all my friends that design with Spice and various CAD software, that Kelly Johnson and crew, designed the SR 71 with slide rules. I'm sure they had computers doing the wind tunnel math, but the bulk of the math was analog/bamboo. I have a copy of MatLab here; it's amazing. But, the old HP gets the most use.
 
Wow! What a Response!

Wow! What a Response!

I think most of you got it, but some spoke out of ignorance and assumption (about TIFF for example, if you want to read a technical paper on it please write me and I'll send the whole thing). One fellow had TIFF down pat.

Some showed faith in Graphic Converter. If you want to know how poor Graphic Converter is take an image transferred on an older proprietary browser, AOL for example, and try to convert it to a JPEG.

I'm afraid BMP is far newer than the earliest digital graphic programs as well. I was using Binuscan along side of Photoshop 2 for awhile, for example; BMP won't help if it's a later development. The QuickTake only works with Apple Software on OS.7.5, where's BMP for that?

Of course some mentioned Magic Nerds (dwarf computer geniuses), and others said to always update as you go, but then again that may be like forgetting to charge one's electric car at night.

The main point is this: digital photography goes into obsolescence at the same rate that lap top computers, OS's, and cell phones do, and as well as upgrades in connectivity (SCSI to wireless, parallel port to USB, for example). Any of these 'improvements' can deny one access to his imagery.

As wonderful as digital photography is today, it is still is very risky business. It's great for instant communication, but piss poor for making lasting art or archiving anything.

I just hope that we don't put out all the horses to pasture too soon.
 
Hopefully not out to pasture but there is no denying that the horses are already well out of the barn.

Oh Two said:
I think most of you got it, ....

....

I just hope that we don't put out all the horses to pasture too soon.
Click to expand...
 
Oh Two said:
Some showed faith in Graphic Converter....
Click to expand...

No, I said it was worth a try. And in many cases, it is.

The main point is this: digital photography goes into obsolescence at the same rate that lap top computers, OS's, and cell phones do, and as well as upgrades in connectivity (SCSI to wireless, parallel port to USB, for example). Any of these 'improvements' can deny one access to his imagery.
Click to expand...

The specifications for standard image formats have settled down considerably since the early days of personal computing. For example, the TIFF format was last revised in 1992.

The difference between then and now is that the core technologies have substantially matured.

If you save your images today in a common and widely accepted standard application (Photoshop; GIMP; Image/J; MATLAB), using a common and widely accepted file format, it should be readable for a long, long time.

Yes, there is risk. There is also substantial risk that I won't be able to get a 35mm slide scanner or photographic paper for printing of negatives over exactly the same time scales that concern us for computers (40-50 years).

The only really reliable way to archive is with prints, produced using archival methods. Whether those prints are made using analog or digital processes is inconsequential. Storing medium or large format negatives is probably also OK. 35mm film (particularly color negs or slides) are probably not a good idea.
 
Last edited:
BMP is in Photoshop 3.0, and I think Photostyler 1.1. I'll check. I did not use anything earlier than Photoshop 3.0, it came bundled with the Kodak DCS200.

BMP is very simple to implement.
 
No Cigar

No Cigar

Semilog:
'The specifications for standard image formats have settled down considerably since the early days of personal computing. For example, the TIFF format was last revised in 1992.'

Very wrong, even US government requirements for TIFF are revised all the time, even within the last year.

Write me for my tech paper discussing jpeg/tiff integration.

Nothing 'settles down' ALL formats remain in flux, adaption and improvement (except the obsolete which becomes static, and what this discussion is all about).

RAW is far from 'settling down'. Where will your RAW camera be in 15 years? Is 'settling down' in fact obsolescence? I think your idea of 'settling down' is a short period (5 to 10 years???) of interchangeability, interface and common usage.

To even imagine that there is some kind of software Rosetta Stone for all this, I'm afraid, is just a dream, while I admit some come close.

But as I said before, hardware is the greatest impasse. Some of my best, and still very useful gear is SCSI. And when it comes to cameras, I have a very old Fuji 2.2 megapixel camera that in my estimation delivers a far better image than most of today's cameras of 6 megapixel, but the memory card for the camera is pretty much obsolete now.
 
Oh Two said:
...digital photography goes into obsolescence at the same rate that lap top computers, OS's, and cell phones do, and as well as upgrades in connectivity (SCSI to wireless, parallel port to USB, for example). Any of these 'improvements' can deny one access to his imagery.
Click to expand...

Digital cameras are succeeded by new models. Digital photography goes on. Laptops are succeeded by new models. Computing goes on.

As wonderful as digital photography is today, it is still is very risky business. It's great for instant communication, but piss poor for making lasting art or archiving anything.
Click to expand...

Most people who buy cameras aren't interested in making art, and that's always been the case. I'm also skeptical about their interest in archiving images for decades.

The flip side of all this is that, because of the nature of the consumer market, developers and manufacturers have an economic incentive to ensure that new software can handle old data. While we certainly saw data formats and protocols made obsolescent in the early and boom years of personal computing, the global dependence on a number of current formats and protocols actually acts as a drag on the commercial acceptance of new approaches.
 
A lot of this is really about standards.

I think the issue of the Quicktake is proprietary format at the dawn of consumer digital photography, before the formats settled down into widely used standards. Similar to weird controls on automobiles until they became standardized in late 1920s. Film emulsions had no real standard ISO in the wet-plate era because of myriad variables. Once dry plates were introduced, the sensitivity could be standardized and you could start using light meters for exposure and developing using clocks instead of inspection.

Units of measurement were all over the map until a couple centuries ago.

I still have my 1995 Compaq 486/100 laptop. Works as well as the day I bought it. It's loaded with the original Windows95 and screams through DoS and WordStar 7, which remains the best word processor I've ever used. [WS 7 could copy to and from the Windows clipboard up till Win2000]. It's getting increasingly difficult to pull data off of it. Has a PC card slot but the OS is too old for USB, etc. I haven't connected to the Internet via modem for more than 4 years now.

I remember our first office PCs. Got them in 1986. Zenith 286s. We were doing our work on typewriters (mix of manuals and IBM Selectrics). The 286 computers with DoS were so hard to figure out that they sat unused for months until a tech-minded colleague started coming in weekends to try to figure them out.

I still have txt files from the mid- and late-'80s that are just fine to read. So it really is all about standards.
 
At Hendon, the Police Driving School in the UK, they used to keep a Lagonda with a central accelerator: clutch, accelerator, brake instead of clutch, brake, accelerator. It was to teach cocky young coppers that they were not exactly the mutt's nuts at driving every car every made.

Cheers,

R.
 
If documentation exists for an image standard, the image can be read-in, interpreted correctly, and written to a different file format that can then be processed. The trick is to find the documentation. Reverse Engineering file formats is not as easy as just reading the spec, but can be done. Some tools exist for doing that, and it is always possible to write custom tools. If you can read the binary stream into memory, ie have the hardware to read the data, the rest is just typing code.
 
Oh Two said:
Semilog:
'The specifications for standard image formats have settled down considerably since the early days of personal computing. For example, the TIFF format was last revised in 1992.'

Very wrong, even US government requirements for TIFF are revised all the time, even within the last year.
Click to expand...

Requirements for TIFF implementation may change. The formal specification has not been updated since 1992. It's here.

Write me for my tech paper discussing jpeg/tiff integration.
Nothing 'settles down' ALL formats remain in flux, adaption and improvement (except the obsolete which becomes static, and what this discussion is all about).

RAW is far from 'settling down'. Where will your RAW camera be in 15 years? Is 'settling down' in fact obsolescence?
Click to expand...

I said nothing about "RAW" because the term does not refer to s specific file format, or even a coherent set of file formats. RAW is a generic term that refers to many different proprietary formats.

I think your idea of 'settling down' is a short period (5 to 10 years???) of interchangeability, interface and common usage.
Click to expand...

No, more like 40 years. Remember that we are only 18 years away from 1992 and the original TIFF specification –- and most TIFF files written in 1992 are still quite readable by a variety of common applications. The fact that some aren't merely confirms that some implementations were sloppy or oddball, or that the original specification contained ambiguities or errors not noticed by some engineers.

I do think that current TIFF files will (generally) be readable in 40 years, because the storage of still images is a rapidly maturing technology. Most JPEGs will probably be o.k., as well.

The example you opened with was the first consumer digicam. It's hardly surprising that it had quirks, and it's hardly surprising that it's no longer supported by current hardware.

To even imagine that there is some kind of software Rosetta Stone for all this, I'm afraid, is just a dream, while I admit some come close.
Click to expand...

You're very good at interpolating things that I neither wrote nor meant.

Please don't do that, O.K.?

But as I said before, hardware is the greatest impasse. Some of my best, and still very useful gear is SCSI. And when it comes to cameras, I have a very old Fuji 2.2 megapixel camera that in my estimation delivers a far better image than most of today's cameras of 6 megapixel, but the memory card for the camera is pretty much obsolete now.
Click to expand...

I don't disagree about hardware. There's no argument that computer hardware (including digital cameras) becomes obsolete rather quickly. But the obsolescence of equipment is not the same as the obsolescence of data -- provided that the data is stored in common formats.

This is microeconomics: if a lot of people have important data in stored in a given a format (e.g., MS .doc), there is an economic incentive to make new software read the format. If a format is obscure, that incentive is weakened. If the format is proprietary (like most RAW formats), the problem is compounded.

So store your data in common, publically-defined formats, or in proprietary formats that are extremely common and have been thoroughly reverse-engineered, and you probably won't lose much over time.

At least with digital files I can keep identical copies of the data at multiple physical locations more or less as soon as it's written. Far, far harder to do that with negatives. Enough harder that I (and most other photographers) don't even try.
 
Last edited:
I used NATO standard image format long before TIFF.

It's been around for a long time. GOES satellite data was distributed in that format, I read it in and displayed it on the IBM Professional Graphics Controller (PGC). It was neat- used run length encoding for image data.
 
Brian Sweeney said:
I used NATO standard image format long before TIFF.

It's been around for a long time. GOES satellite data was distributed in that format, I read it in and displayed it on the IBM Professional Graphics Controller (PGC). It was neat- used run length encoding for image data.
Click to expand...

Brian; I currently use 3 digital cameras. Each produces it's own proprietary version of Raw. I have Nikon, Kodak and Adobe Raw. After saving the raw to optical, I save a version on a HDD and again on the working HDD on my PS/LR box. Upon completion of adjustment to any imagery, I save a Raw and a Jpg to the outboard HDD and will burn archival CDs of any specific files of value. With the changes in media I've seen in the past years, I wonder where this stuff is going to be archived in the future? I shoot a lot of film. I don't worry at all about the film. I think I will always be able to print or scan the film.
 
Film degrades. Color dyes fade. Film gets scratched, deteriorates. "Digital Restoration" is used to bring a number of them back to life. But how many films were lost. Nitrate stock?

If Data is important, it gets transferred to a new system as the old system is retired. The important thing is to be able to read the data as a binary stream, get it off the media. That, and have documentation for the file format. If you can do that, you can have code developed to process just about anything and translate it to just about anything. When my daughter used my graphics package, I output HPGL from FORTRAN code written in 1988, converted it using Coreldraw to a .WMV, and into Powerpoint.

The Kodak ".KC2" RAW format for the DCS200 is not supported my any modern software, and documentation on the file format is not available. HEX Dump. Found what looked like Header information, followed by Image data. Found out the stored image was 1536x1024 and not 1524x1012 as stated for the resolution of the camera. That took an extra 30 minutes to deal with. Converted to BMP and can read it in with most anything. One afternoon of writing code to having an image up and displayed. Image processing is just not that hard to do. Unpack an image into a 2-D array. If it uses a fancy compression scheme- best to have the documentation.

I've been dealing with digital images since 1979. I can't read 7-track takes or 28-track tapes that we used in the early 80s for sensor data. I can still read the Landsat IV images, and SPOT images from the 1980s. Used FORTRAN then, can use it now. Point is- if something is important and has to be retrieved, someone will make it happen.
 
Last edited:
Roger Hicks said:
At Hendon, the Police Driving School in the UK, they used to keep a Lagonda with a central accelerator: clutch, accelerator, brake instead of clutch, brake, accelerator. It was to teach cocky young coppers that they were not exactly the mutt's nuts at driving every car every made.

Cheers,

R.
Click to expand...

What's a "clutch"?
 
The casual stuff, I'll do on digital, but my holidays are shot on film: no need to convert the data to a new medium every couple of years. As far as I can judge, the negs I shot 20 years ago are as good as they were on day one.. Meanwhile I've lost 2 year old digital files due to memory card failures..
 
>I'm afraid BMP is far newer than the earliest digital graphic programs as well. I was
>using Binuscan along side of Photoshop 2 for awhile, for example; BMP won't help if it's
>a later development. The QuickTake only works with Apple Software on OS.7.5,
>where's BMP for that?

I do not understand this statement. BMP is far older than the Camera. Photoshop 3 was out long before the camera, and has the ability to "Save As" BMP. Also, according to some websites, the QuickTake works with release 9 for Apple. I do not know much about apple OS's, but found a site that stated the CODEC was still in OS 9.

BMP is very easy to generate once an image is in memory.

PROGRAM CVTKC2
IMPLICIT NONE
CHARACTER* 80 FILE
INTEGER* 2 COLUMS, ROWS
INTEGER* 4 IMGBGN, PIXELS
PARAMETER ( COLUMS= 1536, ROWS= 1024)
PARAMETER ( PIXELS= 1536* 1024, IMGBGN= Z'13800')
C+++ BEGIN / CMBMP/
C WINDOWS BITMAP HEADER FILE.
INTEGER* 2 FLTYPE
INTEGER* 4 FILESZ, RSVD1, OFFSET, HDRSIZ, IWIDTH, IHEIGHT
INTEGER* 2 CLRPLN, BITPXL
INTEGER* 4 COMPRESS, IMGSIZE, HRES, VRES, CLRINDEX, CLRUSED
LOGICAL* 1 PALETTE
COMMON/ CMBMP/ FLTYPE,
1 FILESZ, RSVD1, OFFSET, HDRSIZ, IWIDTH, IHEIGHT,
2 CLRPLN, BITPXL,
3 COMPRESS, IMGSIZE, HRES, VRES, CLRINDEX, CLRUSED,
4 PALETTE( 4, 0: 255)
CHARACTER* 2 FILETYPE
EQUIVALENCE ( FLTYPE, FILETYPE)
C--- END / CMBMP/
C+++ BEGIN / CMLUNM/
INTEGER* 2 LUINPT, LUOUT, LULIST
COMMON/ CMLUNM/ LUINPT, LUIN, LULIST
C--- END / CMLUNM/
C+++ BEGIN DOS I/O FUNCTION CODES.
C FILE I/O PARAMETERS AND CODES.
INTEGER* 2 CRTNRM, CRTRD, CRTHDN, CRTSYS
INTEGER* 2 OPNRD, OPNWRT, OPNRDW
INTEGER* 2 FRMBGN, FRMCRN, FRMEND
INTEGER* 2 BADFIL, NORMAL
PARAMETER ( CRTNRM= 0, CRTRD= 1, CRTHDN= 2, CRTSYS= 3)
PARAMETER ( OPNRD= 0, OPNWRT= 1, OPNRDW= 2)
PARAMETER ( FRMBGN= 0, FRMCRN= 1, FRMEND= 2)
PARAMETER ( BADFIL= 0, NORMAL= -1)
C--- END DOS I/O FUNCTION CODES.
C LOCAL STUFF.
CHARACTER* 60 PATH
INTEGER* 2 GREY, I, J, K, LENGTH
INTEGER* 2 STATUS, BYTES, PATHLN
LOGICAL* 1 GREYVLU( 2)
EQUIVALENCE ( GREY, GREYVLU( 1))
CHARACTER* 80 STRING, FLNAME
INTEGER* 4 ROWIN, ROWOUT, POSITN
LOGICAL* 1 SCANLINE( 8192)
INTEGER* 2 PXLROW( 4096)
EQUIVALENCE ( PXLROW, SCANLINE)
C EXTERNALS.
INTEGER* 4 LOC
INTEGER* 2 FILOPN, FILCRT, FILCLS, READF, WRITEF, READS, WRITES
INTEGER* 4 MVFLPT
INTEGER* 4 UNSIGN
INTEGER* 2 STRLEN, IEOR, IAND, IOR, FILENG, EXCUTE
CHARACTER* 1 UPCASE
WRITE( *, *) 'PATH TO DCS200 FILES: '
READ( *, 200) PATH
200 FORMAT( A)
PATHLN= STRLEN( PATH)
IF( PATHLN .GT. 0) THEN
IF( PATH( PATHLN: PATHLN) .NE. '\') THEN
PATHLN= PATHLN+ 1
PATH( PATHLN: PATHLN)= '\'
END IF
WRITE( STRING, 400) PATH( 1: PATHLN)
400 FORMAT( 'DIR/B ', A, '*.KC2>TEMPKC2.DAT')
ELSE
STRING= 'DIR/B *.KC2>TEMPKC2.DAT'
END IF
I= STRLEN( STRING)
STATUS= EXCUTE( STRING( 1: I))
LULIST= 1
OPEN( UNIT= LULIST, FILE= 'TEMPKC2.DAT', STATUS= 'OLD')
1010 CONTINUE
READ( LULIST, 300, END= 1000) FLNAME
300 FORMAT( A)
LENGTH= STRLEN( FLNAME)
C OPEN THE INPUT FILE.
IF( PATHLN .GT. 0) THEN
STRING= PATH( 1: PATHLN)// FLNAME( 1: LENGTH)
WRITE( *, *) STRING
ELSE
STRING= FLNAME( 1: LENGTH)
END IF
LENGTH= STRLEN( STRING)
WRITE( *, *) STRING( 1: LENGTH)
LUINPT= FILOPN( STRING( 1: LENGTH), OPNRD)
STRING( LENGTH-2: LENGTH)= 'BMP'
C BUILD THE HEADER INFORMATION FOR THE BMP OUTPUT FILE.
FILETYPE= 'BM'
C SIZE OF FILE IN 32-BIT WORDS.
FILESZ= ( COLUMS* ROWS)/ 4+ 256+ 14+ 1
RSVD1= 0
OFFSET= 1078
HDRSIZ= 40
IWIDTH= COLUMS
IHEIGHT= ROWS
CLRPLN= 1
BITPXL= 8
COMPRESS= 0
IMGSIZE= ROWS* COLUMS
HRES= 0
VRES= 0
CLRINDEX= 0
DO 5 I= 0, 255
GREY= I
PALETTE( 1, GREY)= GREYVLU( 1)
PALETTE( 2, GREY)= GREYVLU( 1)
PALETTE( 3, GREY)= GREYVLU( 1)
GREY= 0
PALETTE( 4, GREY)= GREYVLU( 1)
5 CONTINUE
C OPEN FILE.
WRITE( *, *) ' CREATE: "', STRING( 1: LENGTH), '".'
LUOUT= FILCRT( STRING( 1: LENGTH), CRTNRM)
BYTES= OFFSET
STATUS= WRITEF( LUOUT, FLTYPE, BYTES)
BYTES= COLUMS
C POSITION TO THE LAST ROW.
ROWIN= Z'13800'+ 1536*( ROWS- 1)
DO 10 I= 1, ROWS
POSITN= MVFLPT( LUINPT, FRMBGN, ROWIN)
STATUS= READF( LUINPT, PXLROW, BYTES)
ROWIN= ROWIN- COLUMS
STATUS= WRITEF( LUOUT, PXLROW, BYTES)
10 CONTINUE
STATUS= FILCLS( LUINPT)
STATUS= FILCLS( LUOUT)
GO TO 1010
1000 CONTINUE
STOP 'NORMAL TERMINATION'
END

INTEGER* 2 FUNCTION EXCUTE( CMNDLN)
CHARACTER CMNDLN* ( *)
C DECLARE EXTERNALS.
EXTERNAL EXEC
INTEGER* 2 LEN, EXEC
C DECLARE LOCAL STORAGE.
INTEGER* 2 LENGTH
LOGICAL* 1 CMDINT( 15)
LOGICAL* 1 COMAND( 80), ZERO, CRETRN, BYTE( 2)
INTEGER* 2 I, BGBYTE
CHARACTER* 8 FORMAT
SAVE BYTE, BGBYTE
EQUIVALENCE ( BGBYTE, BYTE( 1))
DATA ZERO/ Z'00'/, CRETRN/ Z'0D'/
C SET COMMAND INTERPRETER PATH TO 'C:\COMMAND.COM'. ZERO TERMINATE.
DATA CMDINT/ 1HC, 1H:, 1H\, 1HC, 1HO, 1HM, 1HM, 1HA, 1HN, 1HD,
1 1H., 1HC, 1HO, 1HM, .FALSE./
C SET COMAND(2): COMAND( 4) TO '/C '.
DATA COMAND( 2)/ 1H/ /, COMAND( 3)/ 1HC/, COMAND( 4)/ 1H /
C USE THE EXEC MACRO SUBROUTINE TO EXECUTE THE COMMAND INTERPRETER.
C PASS CMNDLN BUILT INTO THE COMMAND LINE STRING FOR THE COMMAND INTERPRETER.
C INSERT THE COMMAND LINE INTO COMAND.
LENGTH= LEN( CMNDLN)
C SET FIRST BYTE OF COMAND TO LENGTH.
BGBYTE= LENGTH+ 3
COMAND( 1)= BYTE( 1)
C CREATE A FORMAT STATEMENT TO READ THE COMMAND LINE.
WRITE( FORMAT, 300) LENGTH
300 FORMAT( '( ', I2, 'A1)')
C READ THE COMMAND LINE.
READ( CMNDLN, FORMAT)( COMAND( I), I= 5, LENGTH+ 4)
C TERMINATE COMAND WITH A CARRIAGE RETURN.
COMAND( LENGTH+ 5)= CRETRN
C EXECUTE THE COMMAND AND SAVE THE STATUS.
EXCUTE= EXEC( CMDINT, COMAND)
RETURN
END

INTEGER* 2 FUNCTION FILENG( STRING)
C THIS FUNCTION RETURNS THE POSITION OF THE LENGTH OF THE ROOT OF
C A FILENAME.
CHARACTER STRING*( *)
INTEGER* 2 POSITN, LENGTH, STRLEN
INTEGER* 2 LEN
CHARACTER* 1 BLANK, NULL, PERIOD
DATA BLANK/ ' '/, NULL/ Z'00'/, PERIOD/ '.'/
C GET LENGTH OF THE STRING.
LENGTH= LEN( STRING)+ 1
5 LENGTH= LENGTH- 1
IF( ( STRING( LENGTH: LENGTH) .EQ. BLANK .OR.
1 STRING( LENGTH: LENGTH) .EQ. NULL) .AND. LENGTH .GT. 0)
2 GO TO 5
C IS THIS A NULL STRING?
IF( LENGTH .EQ. 1 .AND.
1 ( STRING( 1: 1) .EQ. BLANK .OR.
2 STRING( 1: 1) .EQ. NULL)) THEN
STRLEN= 0
ELSE
STRLEN= LENGTH
END IF
LENGTH= 0
10 CONTINUE
LENGTH= LENGTH+ 1
C SKIP UP SYNTAX.
IF( STRING( LENGTH: LENGTH+ 1) .EQ. '..') LENGTH= LENGTH+ 1
IF( STRING( LENGTH: LENGTH) .NE. PERIOD .AND.
1 LENGTH .LT. STRLEN) GO TO 10
IF( STRING( LENGTH: LENGTH) .EQ. PERIOD) LENGTH= LENGTH- 1
FILENG= LENGTH
RETURN
END
 
Status
Not open for further replies.
Back
Top Bottom