[9fans] page fit to window does not work on large jpegs

[Ingo Krabbe]

Hey 9fans,

Today I tried to open a quite large jpeg. About 2400x1800 pixel. So first I want an overview of that image. So I choose "Fit in Window" from the page window.
All that this command does is "page: unloadimage", which was not the expected function. Actually I found no way to scale the image down and just get an overview of it.

regards, ingo

[andrey mirtchovski]

change line 452 of /sys/src/cmd/page/rotate.c to
'sysfatal("unloadimage: %r");', compile and run your program again.
the code will now print what the exact error is and we can take it
from there.

[Ingo Krabbe]

Post by andrey mirtchovski
change line 452 of /sys/src/cmd/page/rotate.c to
'sysfatal("unloadimage: %r");', compile and run your program again.

Yes, that was expected somehow:
page: unloadimage: unloadimage: image too wide

Maybe I will take a closer look later.

Post by andrey mirtchovski
the code will now print what the exact error is and we can take it
from there.

[erik quanstrom]

Post by Ingo Krabbe

Post by andrey mirtchovski
change line 452 of /sys/src/cmd/page/rotate.c to
'sysfatal("unloadimage: %r");', compile and run your program again.

page: unloadimage: unloadimage: image too wide
Maybe I will take a closer look later.

/sys/src/libdraw/unloadimage.c:31

you could start by making that constant 12000 or some such.
that will probablly violate some other assumption, but at least
it's a start.

- erik

[Ingo Krabbe]

Post by erik quanstrom

Post by Ingo Krabbe

Post by andrey mirtchovski
change line 452 of /sys/src/cmd/page/rotate.c to
'sysfatal("unloadimage: %r");', compile and run your program again.

page: unloadimage: unloadimage: image too wide
Maybe I will take a closer look later.

/sys/src/libdraw/unloadimage.c:31
you could start by making that constant 12000 or some such.
that will probablly violate some other assumption, but at least
it's a start.

I assume that might be related to Displaybufsize=8000 in draw.h

Post by erik quanstrom
- erik

[erik quanstrom]

Post by Ingo Krabbe

Post by erik quanstrom
you could start by making that constant 12000 or some such.
that will probablly violate some other assumption, but at least
it's a start.

I assume that might be related to Displaybufsize=8000 in draw.h

at least on my system, that symbol is not used.

- erik

[c***@gmx.de]

this is fixed in 9front. the problem is this:

kernel devdraw needs full draw rpc messages in every write(). but
9p has a io unit. libdraws loadimage will fill its its io buffer
with a number of scanlines and then do a rpc until the whole image
is loaded. if the size of a single scanline exceeds the buffer size,
it will fail.

our solution was to make loadimage split the scanlines in that case,
so no matter how wide the image gets, it will get loaded correctly.

also, the compressed image format has a similar limitation. we changed
writememimage to produce uncompressed images if the compressed
blocksize would exceed the buffer.

--
cinap

[erik quanstrom]

Post by c***@gmx.de
also, the compressed image format has a similar limitation. we changed
writememimage to produce uncompressed images if the compressed
blocksize would exceed the buffer.

so only small images are compressed? :-)

- erik

[c***@gmx.de]

just the very wide ones will degrade to uncompressed
format. the alternative would be changing devdraw
to accept infinitely long draw rpcs split over multiple
writes. would require changes in drawterm, inferno, 9vx
plan9... doesnt seem worth the trouble.

--
cinap

[erik quanstrom]

Post by c***@gmx.de
just the very wide ones will degrade to uncompressed
format. the alternative would be changing devdraw
to accept infinitely long draw rpcs split over multiple
writes. would require changes in drawterm, inferno, 9vx
plan9... doesnt seem worth the trouble.

64kb would seem a big enough limit for nearly anything
today. that would allow for 32bpp images up to 16384
pixels wide if uncompressed. so why not just make the iounit
bigger?

also, libdraw shouldn't be making decisions about how wide is
too wide. it should delegate to the device.

- erik

[Charles Forsyth]

It's not the library's choice: anything along the way can further restrict
IO unit, but 8k+IOHDR is a reasonable minimum for

Post by erik quanstrom
so why not just make the iounit
bigger?

[Charles Forsyth]

... graphics

Post by Charles Forsyth
a reasonable minimum for

[erik quanstrom]

Post by Charles Forsyth
... graphics

Post by Charles Forsyth
a reasonable minimum for

except for the fact it's not. even something like a droid x takes
too wide a picture. (>3200 pixels wide.)

this is the change i made, which should give you 64k on a terminal,
and drawterm, if you change the iounit.

; diff -c `{yesterday -n2 unloadimage.c} unloadimage.c
/n/dump/2012/0411/sys/src/libdraw/unloadimage.c:28,34 - unloadimage.c:28,34
werrstr("unloadimage: %r");
return -1;
}
- dy = 8000/bpl;
+ dy = i->display->bufsize/bpl;
if(dy <= 0){
werrstr("unloadimage: image too wide");
return -1;

- erik

[c***@gmx.de]

thats basicly what we did too, plus that if dy <= 0, we
split the scanline that fits in the display buffer and
recursively call unloadimage() on the rest instead of
failing.

the same thing is done with loadimage.

its just writememimage() wich uses a constant for the
chunksize because it doesnt have a bufsize negotiated
from 9p i/o unit by libdraw.

--
cinap

[Charles Forsyth]

Yes, that's a better approach. You need to (try to) adapt to the IO unit as
received, because it can be renegotiated at any Tversion.

Post by c***@gmx.de
thats basicly what we did too, plus that if dy <= 0, we
split the scanline that fits in the display buffer and
recursively call unloadimage() on the rest instead of
failing.

[c***@gmx.de]

yep, figured that out :)

--
cinap