Photon improvement

[Silvester]

Cristian, All the things you mention have been done already, or are planned to be done.

Wallpaper will only be done where the system supports it (SMSQ). I don't plan to do QDOS/Minerva wallpaper, but the output could be used with existing programs that do wallpaper as a job which always is in the background.

I haven't got Dilwyn's email to hand to send final version of FJPEG (for now at least, FGIF and FPNG to be added later), so I hope posting yet another version here is OK (last one!).

This version does proper scaling 4:3 to 2:1 by skipping every third line. You can also output in Sepia (old photos) and greyscale. (GD2 modes only)

[Cristian]

Cristian, All the things you mention have been done already, or are planned to be done.

OK, I got it. The purpose of my previous message was only to summarize.
Thank you very much for your continuous efforts and support

[Giorgio Garabello]

i've seen fjpeg and I've a question: why is an extension and not an executable?

[swensont]

I've tried the most recent version on some jpegs and I keep getting error -19 (bad jpeg). The jpeg files look fine under a number of linux viewers. How can I tell what is "bad" about them? Is there some tool that will provide that info (like Gimp, etc)?

I've tried using different tools to get a background image from a JPEG and have not had a whole lot of luck and was hoping this tool would do it.

BTW, using SMSQmulator.

Tim

[Silvester]

Giorgio Garabello wrote:

> i've seen fjpeg and I've a question: why is an extension and not an executable?

Aha! FJPEG was the first version of my JPEG decoder (1998), once I got it working I then wrote Photon as an executable job. I just posted it here (slightly revised for PIC output) until I got next version of Photon out. That will output PIC (and much more).

swensont wrote:

>.. getting error -19 (bad jpeg).

FJPEG is early version of decoder and is less tolerant of errors in JPEG file (ie. incomplete file). Does it fail with Photon 0.13 or 0j14 ? (EW to get error code).

I have already done code to support progressive JPEGS (each frame increases detail). But -19 error suggest content may have something I haven't encountered. If you still get -19 (not err_ni though) any chance you could send me a copy of example JPEG?

[Derek_Stewart]

Hi,


I thought Dave Westbury wrote Photon, or is this another Photon ???

[Silvester]

I am he, Silvester is just my forum pseudonym.

[Cristian]

I am he

Esteem

[Silvester]

Error -19 is of course err_ni (not implemented), error -22 (unknown error) is bad jpeg.

The images you have must be Progressive type which current Photon and FJPEG do not support. As mentioned, the code for supporting them is done and already working in next Photon. The problem was that Progressive jpegs require a lot of memory to decode. The normal type, Sequential, can be decoded on-the-fly 8 or 16 pixels lines at a time. Progressive types encoded image in several frames - the first holds most significant bits, subsequent frames add more lower order bits (and thus detail) to image. They were intended for slow comms links. It means you need to keep a full image buffer in memory as you accumulate bits. Because of this I have written code to use a 'memory swap' file if needed on these images.

Most jpeg decoders as so fast (and comms links) that you probably won't see the frames being decoded. But I have provided an option on next Photon where you can specify upto which frame you want to decode to. If you like, you can use it as a identity game 'can you recognise this image/person?'. With each subsequent call to photon you can add more detail (Progressive types only though), or some sort of fade-in/fade-out effect

Progressive images encode to a slightly smaller file size than Sequential and are now less encountered (IMHO). There is a very useful utility called 'jpegtrans' that can convert Progressive to Sequential. It does it without any loss of quality (it just decodes to DCT's and them reassembles them). Robert Porto compiled a QL version from old v6 libjpeg, currently version is v9. Beware it can easily run out of QL memory : http://morloch.hd.free.fr/qdos/files/libjpeg6b.zip

To use it just type: jpegtran,'win1_input_jpg','win1_output_jpg'

Or better still, if you run Linux, it's in libjpeg-turbo-progs.

Regarding wallpaper creation, here is a SuperBASIC program suitable for mode 32:

Code: Select all

100 ip$='win1_photo_jpg'
110 bgnd$='395477' : REMark hex RGB background colour
120 :
130 CLS: AT 0,0 : PRINT 'Decoding :'!ip$;
140 op$=ip$(1 TO LEN(ip$)-3) : DELETE op$&'pic'
150 error%=FJPEG(ip$,op$&'pic',32)
160 IF error% THEN PRINT ' - '; : REPORT#1;error% : STOP
170 red%=HEX(bgnd$(1 TO 2))&&$F8
180 blue%=(HEX(bgnd$(5 TO 6))&&$F8)*32
190 green%=HEX(bgnd$(3))DIV 2
200 bgnd=(HEX(bgnd$(3 TO 4))&&$1C)*2048
210 bgnd=bgnd+red%+blue%+green% : b$=HEX$(bgnd,16)
220 ip%=FOP_IN(op$&'pic') : size=FLEN(#ip%)
230 op%=FOP_OVER(op$&'bgi') : WGET#ip%,f%,x%,y%,l%,m%
240 xb%=SCR_XLIM-x% : xbl%=xb%/2 : xbr%=xb%-xbl%
250 yb%=SCR_YLIM-y% : ybt%=yb%/2 : ybb%=yb%-ybt%
260 IF xb%<0 THEN xp%=SCR_XLIM : xr%=2*-xb% : ELSE xp%=x% : xr%=0
270 PRINT\'PIC to BGIMAGE : ' : IF yb%<0 THEN y%=SCR_YLIM
280 y$=FILL$( CHR$(HEX(b$(1 TO 2))) & CHR$(HEX(b$(3 TO 4))),SCR_XLIM*2)
290 FOR n%=1 TO ybt% : PRINT#op%;y$;
300 FOR n%=1 TO y%
310   FOR m%=1 TO xbl% : WPUT#op%;bgnd
320   FOR m%=1 TO xp% : WGET#ip%;d% : WPUT#op%;d%
330   BGET#ip%\FPOS(#ip%)+xr%
340   FOR m%=1 TO xbr% : WPUT#op%;bgnd
350   AT 1,17 : PRINT FPOS(#ip%);' / ';size;'  '
360 END FOR n%
370 FOR n%=1 TO ybb% : PRINT#op%;y$;
380 size=FLEN(#op%) : CLOSE#ip%,#op% : DELETE op$&'pic'
390 IF size<>SCR_XLIM*SCR_YLIM*2 THEN PRINT 'Oops, error' : STOP
400 PRINT 'Done, load wallpaper? (Y/N)' : k$=INKEY$(-1)
410 IF k$=='y' THEN BGIMAGE op$&'bgi'

LRESPR fjpeg_bin first, then run it in display resolution you want to create a BGIMAGE for. If the image is smaller than display then area gets filled in with 24 bit RGB value given in bgnd$ (value shown is my favourite desktop colour on Lubuntu). If image is larger than current display then it just crops output file to top-left of image.

The BGIMAGE file created will be considerbly larger than original jpeg file (but can be loaded quickly from a boot file). Alternately you could just do : Photon;'win1_photo_jpg\w' (no background colour, but done in next Photon). Or invoke Photon, centre image as required then do a SBYTES (as show in Dilwyn's wonderful treatise SMSQE.PDF, page 40)

It's unfortunate that BGIMAGE just takes a screen dump file (whose size was dependent on prevailing display setting). It really should have been implemented to only accept a PIC file of the correct mode. The PIC file could then have been cropped or centered as required for current display size (if needed, by first using a BGCOLOUR_24 filler colour). Perhaps a BGPIC command would be a useful addition to SMSQ GD2?

Regarding SMSQemulator, I would use it more but I find mouse buttons hit/do unreliable, QPAC2 Channels locks up OS, as does as MasterSpy and others. Pity, because it is considerably faster than QPC1/Dosbox on same machine running Lubuntu 15.04

Edit: Update, mouse clicks problems solved in v2.05+ (option on emulator config menu to include delay). Marcel's QPAC2 update solves problem with Channels MasterSpy must be be doing something odd. Last version 3 locks up on entry, whereas old version 1.8 on exiting

[Silvester]

It seems all my hard work implementing progressive jpegs was not in vain, they're making a comeback apparently

http://www.webmonkey.com/2013/01/the-re ... sive-jpeg/